Description of problem: If I'm a debugger, and I call: ptrace(PTRACE_SETOPTIONS, kid, 0, PTRACE_O_TRACEEXIT) for a child process I'm debugging, and if that child process is multi-threaded, then when the process calls _exit(0) instead of the SIGTRAP with the PTRACE_EVENT_EXIT code in the exit status that I expect, I get a 0x7f status that means "stopped with signal 0" Version-Release number of selected component (if applicable): This is in the i686 2.6.21-1.3228.fc7 kernel on my fedora 7 box (dual xeon system). How reproducible: every time I run the test program (which I'll attach). Steps to Reproduce: 1. gcc -o exitcode exitcode.c -lpthread && ./exitcode Actual results: gcc -o exitcode -g exitcode.c -lpthread && ./exitcode waitpid status: 0x7f FAIL: unexpected stop signal 0 Expected results: gcc -o exitcode -g exitcode.c -lpthread && ./exitcode waitpid status: 0x6057f PASS: got SIGTRAP with event code PTRACE_EVENT_EXIT Additional info: I tried the test program on both rhel4 and rhel5 systems and it got expected results (but they were uniprocessors, so if it has something to do with thread timing that might not be an interesting result).
Created attachment 159113 [details] exitcode.c source code to demo bug I swear I included this in the initial bugzilla report, but I just noticed the program doesn't seem to be attached. Trying again.
This also fails on my x86_64 fedora 7 system with kernel 2.6.21-1.3228.fc7, so it doesn't appear to be unique to i386.
Just tried the test program again with the newest 2.6.22.1-33.fc7 kernel update, and this bug appears to be fixed. I now see the proper PTRACE_EVENT_EXIT flag. I guess I'll try marking this as fixed in the current release and see how badly confused I get when I try :-).