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 642968 - GCancellable deadlock when disconnecting
GCancellable deadlock when disconnecting
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: 2011-02-22 15:47 UTC by David Zeuthen (not reading bugmail)
Modified: 2013-10-18 18:23 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Minimal test case (1.76 KB, text/plain)
2011-02-22 20:11 UTC, David Zeuthen (not reading bugmail)
Details

Description David Zeuthen (not reading bugmail) 2011-02-22 15:47:59 UTC
Apparently you can't call g_cancellable_disconnect() from a ::cancelled handler. Here's the stack trace:

Thread 1 (Thread 0x7fe8ba0ac960 (LWP 19089))

  • #0 pthread_cond_wait
    from /lib64/libpthread.so.0
  • #1 g_cancellable_disconnect
    at gcancellable.c line 767
  • #2 auth_request_free
    at shell-polkit-authentication-agent.c line 222
  • #3 auth_request_complete
    at shell-polkit-authentication-agent.c line 318
  • #4 shell_polkit_authentication_agent_complete
    at shell-polkit-authentication-agent.c line 410
  • #5 ffi_call_unix64
    from /usr/lib64/libffi.so.5
  • #6 ffi_call
    from /usr/lib64/libffi.so.5
  • #7 gjs_invoke_c_function
    at gi/function.c line 626
  • #8 js_Invoke
    from /usr/lib64/xulrunner-1.9.2/libmozjs.so
  • #9 ??
    from /usr/lib64/xulrunner-1.9.2/libmozjs.so
  • #10 js_Invoke
    from /usr/lib64/xulrunner-1.9.2/libmozjs.so
  • #11 ??
    from /usr/lib64/xulrunner-1.9.2/libmozjs.so
  • #12 ??
    from /usr/lib64/xulrunner-1.9.2/libmozjs.so
  • #13 js_Invoke
    from /usr/lib64/xulrunner-1.9.2/libmozjs.so
  • #14 ??
    from /usr/lib64/xulrunner-1.9.2/libmozjs.so
  • #15 JS_CallFunctionValue
    from /usr/lib64/xulrunner-1.9.2/libmozjs.so
  • #16 gjs_call_function_value
    at gjs/jsapi-util.c line 1151
  • #17 gjs_closure_invoke
    at gi/closure.c line 267
  • #18 closure_marshal
    at gi/value.c line 128
  • #19 g_closure_invoke
    at gclosure.c line 767
  • #20 signal_emit_unlocked_R
    at gsignal.c line 3252
  • #21 g_signal_emit_valist
    at gsignal.c line 2983
  • #22 g_signal_emit
    at gsignal.c line 3040
  • #23 on_request_cancelled
    at shell-polkit-authentication-agent.c line 296
  • #24 g_closure_invoke
    at gclosure.c line 767
  • #25 signal_emit_unlocked_R
    at gsignal.c line 3252
  • #26 g_signal_emit_valist
    at gsignal.c line 2983
  • #27 g_signal_emit
    at gsignal.c line 3040
  • #28 g_cancellable_cancel
    at gcancellable.c line 652
  • #29 auth_agent_handle_cancel_authentication
    at polkitagentlistener.c line 679
  • #30 auth_agent_handle_method_call
    at polkitagentlistener.c line 290
  • #31 call_in_idle_cb
    at gdbusconnection.c line 4427
  • #32 g_main_dispatch
    at gmain.c line 2440
  • #33 g_main_context_dispatch
    at gmain.c line 3013
  • #34 g_main_context_iterate
    at gmain.c line 3091
  • #35 g_main_loop_run
    at gmain.c line 3299
  • #36 main
    at core/main.c line 707
A debugging session is active.
Comment 1 David Zeuthen (not reading bugmail) 2011-02-22 20:11:12 UTC
Created attachment 181632 [details]
Minimal test case

Here's a test case. It should go in gio/tests. Makefile.am changes:


diff --git a/gio/tests/Makefile.am b/gio/tests/Makefile.am
index 5f49e6c..97710d6 100644
--- a/gio/tests/Makefile.am
+++ b/gio/tests/Makefile.am
@@ -45,6 +45,7 @@ TEST_PROGS +=                 \
        gdbus-message           \
        socket                  \
        pollable                \
+       cancellable             \
        $(NULL)
 
 if OS_UNIX
@@ -212,6 +213,9 @@ socket_LDADD                  = $(progs_ldadd)
 pollable_SOURCE                  = pollable.c
 pollable_LDADD           = $(progs_ldadd)
 
+cancellable_SOURCE               = cancellable.c
+cancellable_LDADD                = $(progs_ldadd)
+
 contexts_SOURCES         = contexts.c
 contexts_LDADD           = $(progs_ldadd) \
        $(top_builddir)/gthread/libgthread-2.0.la
Comment 2 Alexander Larsson 2011-02-23 07:05:42 UTC
From the disconnect docs:

 * Additionally, in the event that a
 * signal handler is currently running, this call will block until the
 * handler has finished.  Calling this function from a
 * #GCancellable::cancelled signal handler will therefore result in a
 * deadlock.

This waiting is to protect the connecting side, so that its code doesn't run
after the callback has been disconnected.

Why do you need to disconnect at the cancellation event? After a cancellation
everything will wind back to a normal error return from the cancellable method, thats generally the place where disconnection happens.
Comment 3 David Zeuthen (not reading bugmail) 2011-02-23 12:52:58 UTC
(In reply to comment #2)
> From the disconnect docs:
> 
>  * Additionally, in the event that a
>  * signal handler is currently running, this call will block until the
>  * handler has finished.  Calling this function from a
>  * #GCancellable::cancelled signal handler will therefore result in a
>  * deadlock.
> 
> This waiting is to protect the connecting side, so that its code doesn't run
> after the callback has been disconnected.

Ah, yeah, I forgot about that. Hmm, I'm wondering if we can do something clever here. At least we should use g_warning() (or even g_critical()) instead of deadlocking so it's clear that it's a programming error...

> Why do you need to disconnect at the cancellation event? After a cancellation
> everything will wind back to a normal error return from the cancellable method,
> thats generally the place where disconnection happens.

The cancellation triggers a D-Bus method return. This includes cleanup and the cleanup includes disconnecting the signal... pretty much run of the mill.. I mean, this is something I expect lots of people to do... right?
Comment 4 David Zeuthen (not reading bugmail) 2011-02-23 12:55:14 UTC
Btw, for gnome-shell I worked around this by just moving the code into an idle handler...
Comment 5 Ray Strode [halfline] 2013-10-18 18:23:55 UTC
more discussion and such in the newer bug so duping forward

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