GNOME Bugzilla – Bug 721074
kqueue: deadlock
Last modified: 2013-12-26 21:05:24 UTC
Created attachment 264894 [details] [review] only lock when we add a monitor Hi. There is a potential deadlock in the kqueue monitoring code which I was able to reproduce by just running gedit. In case an object is already monitored, we lock then return without unlocking it which can then result in a self deadlock. Moving the check _before_ locking works for me. Note that this only happens when your default mutex type is PTHREAD_MUTEX_STRICT_NP (which is the case on BSDx). Toughts?
Hi Antoine, Yes, definetely it is a bug. But the proper solution is to place a new G_UNLOCK before that return, instead of moving G_LOCK. The `missing_subs_list` variable may be concurrently accessed from multiple threads thus it has to be protected with a lock. Dmitry
> Yes, definetely it is a bug. > > But the proper solution is to place a new G_UNLOCK before that return, instead > of moving G_LOCK. > > The `missing_subs_list` variable may be concurrently accessed from multiple > threads thus it has to be protected with a lock. Sure. Here's a new diff, hopefully this is what you had in mind. Thanks.
Created attachment 264895 [details] [review] unlock before returning
Review of attachment 264895 [details] [review]: This is obviously correct and if it fixes the issue, then please commit it. Thanks!
(In reply to comment #4) > Review of attachment 264895 [details] [review]: > > This is obviously correct and if it fixes the issue, then please commit it. > > Thanks! Thank you Ryan. It is in: fb21c8eaab64301591a0e179a42ef25cbd793a6e I think it'd be worth to add it to your list of cherry picks for glib-2-38. It's in OpenBSD ports already.
Comment on attachment 264895 [details] [review] unlock before returning Picked it over just now, thanks.