[uClibc 0001281]: Cross-process mutex unlocking after fork()

[bugs at busybox.net]

The following issue has been SUBMITTED. 
====================================================================== 
http://busybox.net/bugs/view.php?id=1281 
====================================================================== 
Reported By:                inguin
Assigned To:                uClibc
====================================================================== 
Project:                    uClibc
Issue ID:                   1281
Category:                   Posix Threads
Reproducibility:            always
Severity:                   crash
Priority:                   normal
Status:                     assigned
====================================================================== 
Date Submitted:             03-21-2007 03:49 PDT
Last Modified:              03-21-2007 03:49 PDT
====================================================================== 
Summary:                    Cross-process mutex unlocking after fork()
Description: 
In uClibc 0.9.28, file libpthread/linuxthreads/ptfork.c, the malloc mutex
will be locked before calling __libc_fork() and released afterwards. These
lines are prominently marked with "hack alert" warning messages. We use
almost the same fix in our copy of uClibc, except that we've encapsulated
the mutex locks and unlocks in atfork handlers.

There's one problem with this approach. Consider the following sequence:
 1. Parent process calls fork() and locks the malloc mutex
 2. Another thread calls malloc() and queues up for the malloc mutex
 3. Parent calls __libc_fork()
 4. Both parent and child unlock the malloc mutex, sending a signal to the
thread that called malloc() in step 2.

This rogue signal from the child process to one of the parent's threads
lead to occasional and hard to reproduce crashes in our parent process. To
reproduce it more reliably I added a usleep() after locking the mutex and
before actually forking. This gives other threads the chance to queue up
for the malloc mutex. Curiously, I can now easily trigger the problem on a
ppc system while the test works perfectly stable on an arm system with the
same kernel version. I don't know why this appears to depend on the
architecture.

Anyway, the child process must never unlock a mutex that has been
initialized by the parent; it should reinitialize the mutex instead. This
might in turn lead to problems if fork() is invoked from inside a signal
handler while the malloc mutex is held, but I don't know how to solve
that.

====================================================================== 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
03-21-07 03:49  inguin         New Issue                                    
03-21-07 03:49  inguin         Status                   new => assigned     
03-21-07 03:49  inguin         Assigned To               => uClibc          
======================================================================