dead lock in forked child

[Mowry, Robert]

I can understand the motivation behind wanting this to work, but when I
read the POSIX spec for threaded programs that call fork(), it seems
pretty clear that malloc() and free() etc are not defined to be safe to
call in the child process:

http://pubs.opengroup.org/onlinepubs/9699919799/functions/fork.html

which says in part:

A process shall be created with a single thread. If a multi-threaded
process calls fork(), the new process shall contain a replica of the
calling thread and its entire address space, possibly including the states
of mutexes and other resources. Consequently, to avoid errors, the child
process may only execute async-signal-safe operations until such time as
one of the exec 
<http://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html>functi
ons is called. Fork handlers may be established by means of the
pthread_atfork() 
<http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_atfork.h
tml> function in order to maintain application invariants across fork()
calls.

The list of async-signal-safe functions is defined here:

http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#ta
g_15_04

(it's a long way down the page)

Is is that people want to go beyond what the spec calls out - and hence
the request to fix issues like this?  Or are folks not aware they are
attempting to do something that's not really kosher?


-bob

On 10/9/12 6:48 PM, "Salvatore Sanfilippo" <antirez at gmail.com> wrote:

>Sorry now I realize that we just always allocate something in main()
>before doing anything else, so there is no need to touch an RC for
>this.
>
>Looking forward to the next jemalloc release :-)
>Salvatore
>
>On Wed, Oct 10, 2012 at 12:41 AM, Salvatore Sanfilippo
><antirez at gmail.com> wrote:
>> Thank you Jason, I think we'll merge the fix in the Redis 2.6 branch
>> that is currently in release candidate.
>>
>> Cheers,
>> Salvatore
>>
>> On Wed, Oct 10, 2012 at 12:36 AM, Jason Evans <jasone at canonware.com>
>>wrote:
>>> 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
>>> jemalloc-discuss at canonware.com
>>> http://www.canonware.com/mailman/listinfo/jemalloc-discuss
>>>
>>
>>
>>
>> --
>> Salvatore 'antirez' Sanfilippo
>> open source developer - VMware
>> http://invece.org
>>
>> Beauty is more important in computing than anywhere else in technology
>> because software is so complicated. Beauty is the ultimate defence
>> against complexity.
>>        ‹ David Gelernter
>
>
>
>-- 
>Salvatore 'antirez' Sanfilippo
>open source developer - VMware
>http://invece.org
>
>Beauty is more important in computing than anywhere else in technology
>because software is so complicated. Beauty is the ultimate defence
>against complexity.
>       ‹ David Gelernter
>_______________________________________________
>jemalloc-discuss mailing list
>jemalloc-discuss at canonware.com
>http://www.canonware.com/mailman/listinfo/jemalloc-discuss