[PATCH 1/2] Delay pthread_atfork registering.

[Jason Evans]

On Oct 23, 2013, at 9:20 AM, Leonard Crestez <lcrestez at ixiacom.com> wrote:
> You mean between the "malloc_initialized = true;" and "malloc_mutex_unlock(&init_lock);"?

Yes.

> It's not clear what this protects against. malloc_init_hard should complete during the first malloc in the process. As long as nobody forks during the first malloc delaying pthread_atfork should be safe, right?

Consider this comment above jemalloc_constructor() in src/jemalloc.c:

/*
 * If an application creates a thread before doing any allocation in the main
 * thread, then calls fork(2) in the main thread followed by memory allocation
 * in the child process, a race can occur that results in deadlock within the
 * child: the main thread may have forked while the created thread had
 * partially initialized the allocator.  Ordinarily jemalloc prevents
 * fork/malloc races via the following functions it registers during
 * initialization using pthread_atfork(), but of course that does no good if
 * the allocator isn't fully initialized at fork time.  The following library
 * constructor is a partial solution to this problem.  It may still possible to
 * trigger the deadlock described above, but doing so would involve forking via
 * a library constructor that runs before jemalloc's runs.
 */

After your change, there are additional failure modes.  For example, the main thread can create a new thread, malloc, then fork, and if the other thread makes it through malloc initialization (but not to the pthread_atfork() call) prior to the main thread's malloc and fork, then deadlock can occur.  In practice jemalloc_constructor() should make it really hard to hit such races, but I remain paranoid about relaxing the initialization sequence.

Thanks,
Jason