[ python-Bugs-853411 ] After fork in subthread, signals are blocked

SourceForge.net noreply at sourceforge.net
Fri Mar 18 04:45:55 CET 2005

Bugs item #853411, was opened at 2003-12-03 16:55
Message generated for change (Comment added) made by moculus
You can respond by visiting: 

Category: Threads
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Göran Uddeborg (goeran)
Assigned to: Nobody/Anonymous (nobody)
Summary: After fork in subthread, signals are blocked

Initial Comment:
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)


Comment By: Erik Osheim (moculus)
Date: 2005-03-18 03:45

Logged In: YES 

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

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


Comment By: gmanipon (pymonger)
Date: 2004-12-06 21:24

Logged In: YES 

Sorry for the bother.

Was there any resolution to this bug report?


Comment By: Jack Jansen (jackjansen)
Date: 2004-01-26 10:02

Logged In: YES 

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.


Comment By: Steve Muir (hairy_flange)
Date: 2004-01-26 04:04

Logged In: YES 

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.


You can respond by visiting: 

More information about the Python-bugs-list mailing list