Description of problem: when a process is traced it cannot be killed by sending it a signal Version-Release number of selected component (if applicable): RHEL4 pre RC1 How reproducible: consistently Steps to Reproduce: 1.Build the attaced file by doing "gcc -o suspend suspend_thread.c -lpthread - D_REENTRANT" 2. run ./suspend 3. Actual results: On EL4 pre-rc1: [~/tests/64/thread_suspension]./suspend_thread Thread 13742720(7344) is started. thread 7344 is stopped (the application is hanged and cannot be killed) Expected results: On EL3 U3: [~/tests/64/thread_suspension]./suspend Thread 13662416(4942) is started. thread 4942 is stopped Segmentation fault Additional info: this is the rootcause of bugzilla #139815
Created attachment 108684 [details] test case to demonstrate the problem
Created attachment 109114 [details] machine-independent version of the test case This is a modified version of the given test case, that can be compiled on any architecture and demonstrates the problem on x86 using the current upstream kernel. This version can also take a signal number argument on its command line. Using this with non-coredump signals demonstrates that there is no problem except in the coredump case.
Created attachment 109116 [details] three-thread version of the test case This version of the test case has three threads, so that the ptracer, the ptracee, and the thread causing the core dump and all separate. Some approaches to the fix work for the prior test case but not for this one.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2005-420.html