Re: compiler optimization causing issues with glib

[Mike <puffy taco gmail com>]

On Tue, Jun 5, 2012 at 1:51 PM, Mike <puffy taco gmail com> wrote:
> On Tue, Jun 5, 2012 at 1:28 PM, Colin Walters <walters verbum org> wrote:
>> On Tue, 2012-06-05 at 13:20 -0500, Mike wrote:
>>
>>> I'm fairly convinced at this point that it is something in libc, but
>>> I'm not sure that it isn't acting to spec with regards to allowed
>>> behavior.
>>
>> Just to be clear, *which* libc are we talking about?  I'm guessing
>> eglibc?
>
> Yeah, looks to be based on eglibc-2.11.1 (not sure if it is pure or
> not) -- it comes with CodeSourcery's ARM 2010q1-202 release of their
> Linux gnueabi compiler.
>
>>> I've walked through the glib code for spawning a process,
>>> and everything looks good with regards to the requirements of
>>> fork/exec as well as the signal handler for SIGCHLD.
>>
>> Yeah, I did a pass through the spawning code last year and fixed
>> a few minor cases where we were missing EINTR handling (which only
>> matter on non-Linux UNIX), but other than that it's always been pretty
>> robust.
>>
>>>  The fact that it
>>> gets caught in a futex for malloc makes me think that the issue
>>> relates to the usage of multiple threads and then the fork inside of
>>> g_spawn_async.  Most documentation I've read says fork and pthreads
>>> don't always work well together.
>>
>> Yes.  See https://bugzilla.gnome.org/show_bug.cgi?id=659326 for some
>> useful discussion.  In particular
>> https://bugzilla.gnome.org/show_bug.cgi?id=659326#c24 was a major
>> discovery for me at least.
>>
>> Basically, for each process, you need to choose between one of:
>>
>> * no shared address space between schedulable entities
>> * forking (without a following exec)
>> * threads
>>
>> GLib uses threads, so it excludes you from using fork-without-exec.
>>
>>> In any case, I've worked around it by forking a process early before
>>> glib init/main thread that is connected via a pipe.  This child
>>> process handles all of the forking requests of the parent and does not
>>> use pthreads or gdbus.  I have run it non-stop for a couple days, no
>>> issue.  Previously I would have issues after a few minutes.
>>
>> If that works, then OK, but I'd be pretty curious what commit a
>> bisection of glib landed you on.  It's fairly automatable.
>
> Not sure what to look for here.  I have tested glib 2.26.0 and 2.32.3,
> both had issues.  So I don't have a defined range to work on.

FYI, I just tried the test case in [1] and it hangs for me.  So I
think that makes a fairly clear case that this issue is eglibc, and
not glib.  Sounds like my work-around will do just fine, as would
upgrading my eglibc.  Thanks for all your help!

[1] https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/838975