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