On Tue, Jun 5, 2012 at 12:54 PM, Colin Walters <walt...@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. _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list