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_______________________________________________
jemalloc-discuss mailing list
[email protected]
http://www.canonware.com/mailman/listinfo/jemalloc-discuss
