Red Hat Bugzilla – Bug 111136
Processes forked from Python subthreads block signals
Last modified: 2007-11-30 17:06:59 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030922 Description of problem: When a Python program starts a new thread, and this new thread forks, the forked process ingores signals. It will not terminate, or dump core if that would be applicable, when it receives a signal. Version-Release number of selected component (if applicable): python-2.2.3-5 (kernel-2.4.21-4.EL glibc-2.3.2-95.6) How reproducible: Always Steps to Reproduce: 1.Run the attached test case. Actual Results: After execution of the parent program threads finishes, there is still a python process around, continuing to sleep. Expected Results: The child process should have died and produced a core. Additional info: Apparently, Python subthreads blocks signals. /proc/*/status for subthreads includes the line SigBlk: ffffffff7ffbfeff The Python documentation says one should only install signal handlers in the main thread, and only the main thread will recieve signals. So this is probably in order. But when the subthread forks, the new process inherits this signal mask, which seems to be incorrect behaviour. I would assume, if Python sets this signal mask for threads, it should also reset it again after a fork. At first this appears to be a Python bug, and maybe I should report it upstreams. But I'm not sure if it in some way interacts with the NPTL fixes of Red Hat, I thought it was safer to start here.
Created attachment 96234 [details] Python program illustrating the behaviour.
After some additional investigations, we have reproduced this on Sun Solaris too. I assume this means it is a Python rather than Red Hat bug, and I've reported it to their bug system: https://sourceforge.net/tracker/?func=detail&aid=853411&group_id=5470&atid=105470
Thanks for your help, I was going to try to reproduce it but didn't get around to do it.