Bug 111136 - (IT_57659) Processes forked from Python subthreads block signals
Processes forked from Python subthreads block signals
Status: CLOSED UPSTREAM
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: python (Show other bugs)
3.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Mihai Ibanescu
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-11-28 07:14 EST by Göran Uddeborg
Modified: 2007-11-30 17:06 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-04-05 16:35:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Python program illustrating the behaviour. (394 bytes, text/plain)
2003-11-28 07:17 EST, Göran Uddeborg
no flags Details

  None (edit)
Description Göran Uddeborg 2003-11-28 07:14:18 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.
Comment 1 Göran Uddeborg 2003-11-28 07:17:27 EST
Created attachment 96234 [details]
Python program illustrating the behaviour.
Comment 2 Göran Uddeborg 2003-12-03 11:58:17 EST
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
Comment 3 Mihai Ibanescu 2003-12-03 11:59:35 EST
Thanks for your help, I was going to try to reproduce it but didn't
get around to do it.

Note You need to log in before you can comment on or make changes to this bug.