child reaping race conditions with system()

Robin Haberkorn rh at travelping.com
Thu Aug 26 16:34:42 UTC 2010


Greetings,

I recently came across something I'm not quite sure whether
it's a bug.
Suppose two threads (NPTL) try to reap the same child process
using waitpid. Naturally there will be a race condition -
which thread reaps the child and retrieves the status will be
undefined. But what about the system() call (stdlib.h)?
It's not thread-safe but it's said to *block* SIGCHLD in
order to prevent the application from catching the signal,
effectively preventing race conditions in case the signal
handler would try to reap children (i.e. any child).
Otherwise this could be a problem even in single-threaded
programs.
uClibc's current implementation (and also eglibc's) uses
sigprocmask to mask out SIGCHLD temporarily. This works
fine in a single-threaded environments, but not if multiple
threads are involved.
The attached test program demonstrates that point. system()
invoked in the thread will most of the time fail and errno
contain the "No child processes" code while the child
in question will have been reaped by the signal handler.
This happens on NPTL uClibc (master branch,
revision 0d6ee549bc86fd330672a79d9a87d2c3825eea67) as well as
on glibc.
Not surprisingly fixing both thread's signal masks with
pthread_sigmask (having it masked out in every thread until
after system() returns). Unfortunately this is not an option
for the kind of program I'm trying to fix it doesn't seem to
be possible to set the signal mask of an arbitrary thread
(other than the one calling pthread_sigmask).
Another obvious workaround for programs like that is to
prevent the signal handler from reaping any child but only
those children we are actually interested in. It should also
be possible to synchronize the SIGCHLD processing in the main
thread and secure system() and waitpid() calls with a mutex.
Both of these options are possible in my case (of course it's
a bit more tricky since the attached program is only a very
simplified model).
Nevertheless I wanted to make sure that this is actually
wanted behaviour.

cheers,
Robin Haberkorn

-- 
-- 
------------------ managed broadband access ------------------

Travelping GmbH               phone:           +49-391-8190990
Roentgenstr. 13               fax:           +49-391-819099299
D-39108 Magdeburg             email:       info at travelping.com
GERMANY                       web:   http://www.travelping.com


Company Registration: Amtsgericht Stendal Reg No.:   HRB 10578
Geschaeftsfuehrer: Holger Winkelmann | VAT ID No.: DE236673780
--------------------------------------------------------------

-- 
-- 
------------------ managed broadband access ------------------

Travelping GmbH               phone:           +49-391-8190990
Roentgenstr. 13               fax:           +49-391-819099299
D-39108 Magdeburg             email:       info at travelping.com
GERMANY                       web:   http://www.travelping.com


Company Registration: Amtsgericht Stendal Reg No.:   HRB 10578
Geschaeftsfuehrer: Holger Winkelmann | VAT ID No.: DE236673780
--------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: childrace2.c.gz
Type: application/x-gzip
Size: 473 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/uclibc/attachments/20100826/b882ef94/attachment.bin>


More information about the uClibc mailing list