Re: Forks, slices and threads: Can you make GSlice deadlock?

[Chris Vine <chris cvine freeserve co uk>]

On Thu, 6 Dec 2012 21:25:47 +0100
David Nečas <yeti physics muni cz> wrote:
> can g_slice_alloc() be made to deadlock simply by some bad sequence of
> GLib function calls, considering the calling program does not, of
> course, hold any GLib lock explicitly?  (Without a GLib bug, that is.)
> 
> I am starting to suspect a problem in GSlice interaction with threads.
> But I cannot report anything to bugzilla because I am unable to get to
> the core of the problem.
> 
> My program (test program for a library) does g_test_trap_fork() and
> the child creates worker threads with g_thread_new(), sends them
> tasks with GAsyncQueue and cancels the tasks using GCancellables.
> 
> Occasionally, a seemingly innocent g_thread_new() call deadlocks in
> g_slice_alloc(), see the backtrace below for how and where exactly.
> If it happens, it happens in the child soon after forking.
> 
> I canNOT reproduce any deadlock if:
> - G_SLICE=always-malloc is set,
> - g_test_trap_fork() is not used and the test is run directly in the
>   main program,
> - under valgrind (also, it reports no errors),
> - I print anything to stderr in g_slice_alloc() – infuriating, but so
> it works.

I am sure you already know this, but assuming you are using the POSIX
backend, POSIX does not allow you to fork() from a multi-threaded
process and then call any non-async-signal-safe functions in the
child (all you are really supposed to do is set up your pipes and then
exec()).

So for your scheme to work, the parent before forking must be single
threaded.  The kind of symptom you report is what you would expect if
it is multi-threaded.

Chris