Red Hat Bugzilla – Bug 242694
utrace: PTRACE_EVENT_EXIT report gets wrong wait status for group exit
Last modified: 2007-11-30 17:12:06 EST
Description of problem:
When tracing a multithreaded program that is killed by a signal using ptrace on
a Fedora kernel, I get very strange events reported by ptrace.
I have attached a test case that traces a process with two threads, sends a
SIGINT signal to the threads and prints the events that ptrace reports.
If you compile the test case with "gcc -lpthread -o ptrace-bug2 ptrace-bug2.c"
and run it on a vanilla 126.96.36.199 kernel, you get the expected messages (here
with manual annotations):
tid 2992: signal 19, ptrace event 0 SIGSTOP to parent from PTRACE_ATTACH
tid 2992: signal 5, ptrace event 3 SIGTRAP|PTRACE_EVENT_CLONE to parent
tid 2992: signal 2, ptrace event 0 SIGINT reaches the process
tid 2992: signal 5, ptrace event 6 SIGTRAP|PTRACE_EVENT_EXIT to parent
tid 2993: signal 5, ptrace event 6 SIGTRAP|PTRACE_EVENT_EXIT to child
tid 2993: terminated by signal 2 Child killed by signal
tid 2992: terminated by signal 2 Parent killed by signal
If you run the test case on the Fedora kernel the signal is reported multiple
times, and you don't get and PTRACE_EVENT_EXIT events:
tid 3201: signal 19, ptrace event 0
tid 3201: signal 5, ptrace event 3
tid 3201: signal 2, ptrace event 0
tid 3201: signal 2, ptrace event 0 SIGINT reported again???
tid 3202: signal 2, ptrace event 0 And again???
tid 3202: terminated by signal 2
tid 3201: terminated by signal 2
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Compile and run the attached test case.
SIGINT reported multiple times, no PTRACE_EVENT_EXIT events.
Same ptrace events as vanilla kernel.
Created attachment 156221 [details]
Reproduced on my upstream+utrace devel kernel on x86_64.
I've fixed this in the utrace development code.
*** Bug 242635 has been marked as a duplicate of this bug. ***
Created attachment 156966 [details]
test case for second failure scenario
Bug 242635 had this second test case for the same underlying bug.
The fix seems to have gotten into kernel-188.8.131.52-27.fc7, at least I can't
reproduce the problem any more.