[PATCH 1/2] Delay pthread_atfork registering.
jasone at canonware.com
Wed Oct 23 13:00:36 PDT 2013
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);"?
> 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.
More information about the jemalloc-discuss