dead lock in forked child

[Jason Evans]

On Jun 1, 2012, at 11:31 AM, Jason Evans wrote:
> On May 25, 2012, at 2:02 AM, Jokea wrote:
>> I've found that a forked child runs into dead lock in a multithreaded application.
> 
> jemalloc calls pthread_atfork() during initialization, but the test program does no allocation in the main thread before forking, and it launches threads that race with it.  It appears that one of those threads gets part way through allocator initialization before the fork occurs, which leaves the allocator in an inconsistent state (init_lock locked, but initialization incomplete).  The simple workaround is to allocate something before forking.
> 
> A general fix in jemalloc is messy at best.  The possibilities that come to mind are 1) intercepting pthread_create() (or all fork-like system calls) much as the lazy locking code in mutex.c does and forcing allocator initialization, or 2) using a library initializer (function specified via compiler attribute to be run during library load) to force allocator initialization.  Both of these approaches are somewhat fragile; dlsym(RTLD_NEXT, …) can break if other libraries play similar games, and library initializers don't run early enough to prevent all possible failures.  In any case, I'll make a note to experiment with (2).

I just committed a fix for this bug:

	http://www.canonware.com/cgi-bin/gitweb.cgi?p=jemalloc.git;a=commitdiff;h=20f1fc95adb35ea63dc61f47f2b0ffbd37d39f32

It turned out that there were also some mutex acquire/release calls missing in the prefork/postfork functions, but most applications would not have exercised the code necessary to cause related deadlocks.

Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jemalloc.net/mailman/jemalloc-discuss/attachments/20121009/42f93079/attachment.html>