GNOME Bugzilla – Bug 320886
GSource is unreffed while holding main context lock
Last modified: 2011-02-18 16:13:19 UTC
Version details: latest breezy I am seeing a lockup in a program. Here are partial stack traces from two threads:
+ Trace 63937
When in python, code holds the python global interpreter lock (GIL lock). The main python thread drops the GIL lock and goes into g_main_loop_run(). Then a property notification comes in from another thread. This grabs the GIL lock, does a g_idle_add to push a python GSource onto the main context (grabbing the context lock), and then drops out. The main thread gets around to handling the python GSource, which calls the gsource without the main context lock. It grabs the GIL lock, does its thing, and then releases it. Then because the idle handler returned FALSE, g_main_dispatch unrefs the closure. However it calls the unref function with the main context lock, and the unref function will grab the GIL lock. In the mean time if the other thread does a g_idle_add from within the GIL lock we have a nice ABBA deadlock. Am working on a patch.
I think it's sufficient just to move the LOCK_CONTEXT line from gmain.c:1939 to after then unref at line 1942. All of the other calls to GSourceCallbackFuncs->unref in an explicitly-unlocked section, e.g. lines 969, 1168, and 1439.
I think you are right about the unref. I wonder about the calls to cb_funcs->ref and cb_funcs->get in g_main_dispatch() though, which are both done with the context lock held.
both ->get and ->ref don't go outside of their functions, ->unref does though. AFAICS
ah, ok looks good then
2005-11-07 Matthias Clasen <mclasen@redhat.com> * glib/gmain.c (g_main_dispatch): Don't call cb_funcs->unref while holding the context lock. (#320886, Andy Wingo)