Re: Strange dead lock with g_threads_enter

[Wei-Ning Huang <aitjcize gmail com>]

Hi Chris,

Thanks for your great help!!!

I finally find out why the deadlock always occurs after 5 minutes.
My applications has a function the autosave the document every X minute,
and I use the g_timeout_add_seconds with callback to handle it. However
the callback contains a line 'while (gtk_events_pending())
gtk_main_iteration()'.
That is the reason why the deadlock occurs!!! I remove the line and the
deadlock is gone!

Big thanks for your help, learned a lot from your reply :)

Best regards,
Wei-Ning Huang

2011/3/7 Chris Vine <chris cvine freeserve co uk>

> On Sun, 6 Mar 2011 16:03:43 +0000
> Chris Vine <chris cvine freeserve co uk> wrote:
> > On Sun, 6 Mar 2011 10:57:24 +0800
> > Wei-Ning Huang <aitjcize gmail com> wrote:
> [snip]
> > > I'm starting to think it's the bug of gtk+, or perhaps the
> kernel?
> > > btw, I'm using Arch Linux with Kernel 2.6.37(autogroup patched),
> > > Gtk+ 2.22.
> > >
> > > SI once suspect that it maybe something to do with the autogroup
> > > patch I'm using, so I switch to the
> > > default 2.6.37 kernel. The result is the same.. still deadlocks.
> > >
> > > frustrated ... (but glad that this didn't happen on ubuntu)
> >
> > In theory it could be a bug in glib, gtk+ or the kernel.  If, say,
> > your motion_compile_thread() function is the only function executed
> > by the test thread and never acquires any other locks than your test
> > mutex, and you do not have a livelock, then I think you are right to
> > be worried about that. Otherwise, it is more likely to be a bug in
> > your code, and the fact that it works on ubuntu is not particularly
> > indicative of anything, since this may just be the result of timing
> > differences or different scheduling policies.
>
> By the way, your first code did not treat the gdk global lock as 'Lock
> 1' and you did not indicate in your latest e-mail whether you have
> corrected that: I should not even think about a glib/gtk+/kernel bug
> until you have done so.
>
> To take an example, if your test thread is started from a gtk+ signal
> handler, the thread will be started holding the gdk global lock, and
> therefore your 'while' loop will acquire 'cp_mutex' holding that lock.
> If another thread calls gdk_threads_enter() while holding cp_mutex, you
> are in line for a deadlock just from that.
>
> Chris



-- 
AZ Huang <http://berelent.blogspot.com/>