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)
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.
Apparently, Python subthreads blocks signals. /proc/*/status for
subthreads includes the line
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:
Thanks for your help, I was going to try to reproduce it but didn't
get around to do it.