After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 711006 - GCancellable: connect -> cancel deadlock
GCancellable: connect -> cancel deadlock
Status: RESOLVED DUPLICATE of bug 705395
Product: glib
Classification: Platform
Component: gio
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2013-10-28 12:52 UTC by Colin Walters
Modified: 2013-10-28 18:24 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
stack (8.36 KB, text/plain)
2013-10-28 12:52 UTC, Colin Walters 		Details

Description Colin Walters 2013-10-28 12:52:59 UTC 
Created attachment 258295 [details]
stack

This may have been filed before, but I just hit this deadlock on gnome-shell in RHEL7 beta. 

From what I can tell the GCancellable mutex is non-recursive, so it's a simple case of calling cancel() inside connect() will deadlock, and the fact the GDBus thread is *also* blocked on that mutex is just a red herring.

Is this just a case of "applications should never do that"?  I neglected to get a JS backtrace unfortunately =/

If there were a way we could make this work it'd be nice, since I suspect this is part of a complex chain of cleanup inside the shell.
Comment 1 Allison Karlitskaya (desrt) 2013-10-28 18:24:46 UTC 
Indeed, calling further cancellable operations from inside of connect() is unsupported and has always been.

that said, Alex fixed this with his (now reverted) commit in bug 705395.  We reverted it only because it landed during hard freeze, a day before the release.

We should recommit that part of the patch now (master only) to make this go away.
Comment 2 Allison Karlitskaya (desrt) 2013-10-28 18:24:59 UTC 

*** This bug has been marked as a duplicate of bug 705395 ***