|
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.
|
Relationships 
