On Thu, 6 Dec 2012 21:25:47 +0100 David Nečas <y...@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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
