This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: After fork in subthread, signals are blocked
Type: Stage:
Components: Interpreter Core Versions: Python 2.2
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: goeran, hairy_flange, jackjansen, moculus, mwh, pymonger
Priority: normal Keywords:

Created on 2003-12-03 16:55 by goeran, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
p goeran, 2003-12-03 16:55 Test case
Messages (8)
msg19245 - (view) Author: Göran Uddeborg (goeran) Date: 2003-12-03 16:55
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.

I attach a test case which illustrates the behaviour. 
In this example, the child process is sent a SEGV
signal from the subthread of the parent process.  This
should cause the child process to die and produce a
core.  But execution of the parent program threads
finishes, there is still a python process around,
continuing to sleep.

Apparently, Python subthreads blocks signals.  On
Linux, /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 makes sense.  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.

I've seen this on these two platforms:
Python 2.2.3 on Red Hat Linux RHEL 3WS (IA32)
Python 2.2.1 on Sun Solaris 8 (Sparc)
msg19246 - (view) Author: Steve Muir (hairy_flange) Date: 2004-01-26 04:04
Logged In: YES 
user_id=960132

I just submitted a bug report that is a duplicate of this bug
(apologies!), I observed the same behaviour with the Python
shipped with Mac OS X (Python 2.3), and Python 2.2.2 on
RedHat/x86, but Fink Python 2.2.3 for OS X does not have
this bug.
msg19247 - (view) Author: Jack Jansen (jackjansen) * (Python committer) Date: 2004-01-26 10:02
Logged In: YES 
user_id=45365

I have absolutely no idea where the bug could be, someone better 
versed in the threading ideosyncracies of the various platforms 
needs to look at this, but I do want to point at hairy_flange's 
comment that fink-python 2.2.3 on OSX does *not* exhibit the bug 
(while on other platforms it does). It may be worthwhile to 
download a fink-python in source form, and see whether they do 
any configure magic.
msg19248 - (view) Author: gmanipon (pymonger) Date: 2004-12-06 21:24
Logged In: YES 
user_id=1173063

Sorry for the bother.

Was there any resolution to this bug report?
msg19249 - (view) Author: Erik Osheim (moculus) Date: 2005-03-18 03:45
Logged In: YES 
user_id=542811

This bug is still around. I have been experiencing it
firsthand: if I write a simple program with one parent and
one child thread and run rsync in the parent thread (via
os.system), all is well. In the child thread it hangs
indefinitely.

After putting a bunch of debugging into rsync, I discovered
that a USR2 signal was getting sent but never received, and
rsyncs parent thread was waiting for the child to exit, and
that the child was sleeping (having not gotten the signal).

Is there any clue as to why this happens? This has been
widely observed on Linux 2.6.* (this particular case affects
Gentoo).
msg19250 - (view) Author: Michael Hudson (mwh) (Python committer) Date: 2005-03-18 08:59
Logged In: YES 
user_id=6656

I think this should be fixed in Python 2.4.
msg19251 - (view) Author: Erik Osheim (moculus) Date: 2005-03-21 05:07
Logged In: YES 
user_id=542811

I can confirm that on my install of 2.4, I no longer get
this problem.
msg19252 - (view) Author: Michael Hudson (mwh) (Python committer) Date: 2005-03-26 10:41
Logged In: YES 
user_id=6656

Good.  Closing.
History
Date User Action Args
2022-04-11 14:56:01adminsetgithub: 39651
2003-12-03 16:55:59goerancreate