Re: compiler optimization causing issues with glib

[Mike <puffy taco gmail com>]

On Tue, Jun 5, 2012 at 12:54 PM, Colin Walters <walters verbum org> wrote:
> On Fri, 2012-06-01 at 11:33 -0500, Mike wrote:
>
>> If you read the example program, you will see in my test that I simply
>> call exit in the child -- that's it.  That meets your requirement.
>
> There is one issue in your code; you shouldn't be calling
> waitpid(-1, ...).  That would break any GChildWatchSource watches that
> exist in the process.  Instead, use waitpid(pid, ...).
>
> That's not the bug though, assuming that as you say you're just
> using g_spawn_async().
>
> The bug is likely to be in kernel/libc then.  Though bisecting[1]
> through GLib would help you narrow down what change caused it.

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.  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.  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.  It could be that the libc I have on
my embedded platform is slightly different than on my laptop or that
it is just down to timing.

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.