Re: Forks, slices and threads: Can you make GSlice deadlock?
On Fri, 7 Dec 2012 22:37:27 +0100 David Nečas wrote: > On Fri, Dec 07, 2012 at 08:44:01PM +, Chris Vine wrote: > > ... > > So for your scheme to work, the parent before forking must be single > > threaded. > > As I have learnt the hard way, this is not something I can ensure even > the program does not use any multi-threading itself because libraries > may. Even apparently very innocent programs can exhibit weird > threading-related bugs. And while it is a sort of gray area, starting > to use threads internally is rarely considered an ABI breakage. So, > unfortunately, the conditions you listed can be reduced to ‘it will > never work’ in practice. > > Anyway, I do not attempt to do this kind of fork & not-exec in real > Gtk+ applications. So I'm looking forward to a better solution for > unit tests which is discussed in the bugzilla bug mentioned by > Matthias. Ah, OK. I am not a glib developer. I just (i) follow this mailing list because I maintain a library which happens to use glib, and (ii) know what POSIX says. It would be hard rations if introducing threads were treated as ABI or API breakage, and anyway a threading option (now compulsory) has been in glib from the outset. Having now read the bug reports another poster has referred to, the better conclusion is that the test function in question was wrong at the outset. Chris ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Forks, slices and threads: Can you make GSlice deadlock?
On Fri, Dec 07, 2012 at 08:44:01PM +, Chris Vine wrote: > ... > So for your scheme to work, the parent before forking must be single > threaded. As I have learnt the hard way, this is not something I can ensure even the program does not use any multi-threading itself because libraries may. Even apparently very innocent programs can exhibit weird threading-related bugs. And while it is a sort of gray area, starting to use threads internally is rarely considered an ABI breakage. So, unfortunately, the conditions you listed can be reduced to ‘it will never work’ in practice. Anyway, I do not attempt to do this kind of fork & not-exec in real Gtk+ applications. So I'm looking forward to a better solution for unit tests which is discussed in the bugzilla bug mentioned by Matthias. Regards, Yeti ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Forks, slices and threads: Can you make GSlice deadlock?
On Thu, 6 Dec 2012 21:25:47 +0100 David Nečas 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
Re: Forks, slices and threads: Can you make GSlice deadlock?
On Fri, Dec 07, 2012 at 05:53:57AM -0500, Matthias Clasen wrote: > See https://bugzilla.gnome.org/show_bug.cgi?id=679683 > g_test_trap_fork is just a bad idea, doubly so with threads (and every > glib program is using threads nowadays)a Thanks, somehow, I missed that bug. Regards, Yeti ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Forks, slices and threads: Can you make GSlice deadlock?
On Thu, Dec 6, 2012 at 3:25 PM, David Nečas wrote: > > So, they are all trying to lock allocator->slab_mutex in GSlice. > But nothing seems to hold it. > Could that be messed up by forking somehow? > > Could you please advise how to debug it further, to rule out the > possibility of GLib bug, if nothing else? > See https://bugzilla.gnome.org/show_bug.cgi?id=679683 g_test_trap_fork is just a bad idea, doubly so with threads (and every glib program is using threads nowadays) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
