dbusmenu assumes GDBus cancellation is reliable (and it's not)

StacktraceTop:
 menuproxy_build_cb (object=<optimized out>, res=<optimized out>, user_data=0x19bfee0) at /build/buildd/libdbusmenu-0.5.94/./libdbusmenu-glib/client.c:1071
 g_simple_async_result_complete (simple=0x19d1060) at /build/buildd/glib2.0-2.31.20/./gio/gsimpleasyncresult.c:744
 complete_in_idle_cb (data=0x19d1060) at /build/buildd/glib2.0-2.31.20/./gio/gsimpleasyncresult.c:756
 g_main_dispatch (context=0x191de40) at /build/buildd/glib2.0-2.31.20/./glib/gmain.c:2510
 g_main_context_dispatch (context=0x191de40) at /build/buildd/glib2.0-2.31.20/./glib/gmain.c:3047

Status changed to 'Confirmed' because the bug affects multiple users.

This looks like a dbusmenu bug. dbusmenu does this call:

                        g_dbus_proxy_new(priv->session_bus,
                                         G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START,
                                         dbusmenu_interface_info,
                                         priv->dbus_name,
                                         priv->dbus_object,
                                         DBUSMENU_INTERFACE,
                                         priv->menuproxy_cancel,
                                         menuproxy_build_cb,
                                         client);

and makes no assurances that 'client' will continue to be around long enough to receive the results. If 'client' gets freed before then the call to menuproxy_build_cb() will crash.

That said, there is this code on the other side:

        /* NOTE: We're not using any other variables before checking
           the result because they could be destroyed and thus invalid */
        GDBusProxy * proxy = g_dbus_proxy_new_finish(res, &error);
        if (error != NULL) {
                g_warning("Unable to get menu proxy: %s", error->message);
                g_error_free(error);
                return;
        }

        /* If this wasn't cancelled, we should be good */
        DbusmenuClient * client = DBUSMENU_CLIENT(user_data);

so even though the client may not be around, the callback should return before attempting to deal with the client.

The cancellable is cancelled from the dispose().

It seems that it is not possible for multiple concurrent calls to get stacked (ie: and the cancellable overwritten with a new one) because of this check:

                /* Check to see if we're already building one */
                if (priv->menuproxy_cancel == NULL) {
                        priv->menuproxy_cancel = g_cancellable_new();

                        g_dbus_proxy_new(priv->session_bus,

Package: indicator-appmenu 0.3.92-0ubuntu1
ProcCmdline: /usr/lib/indicator-appmenu/hud-service

After a bit more research the problem is clear: GDBus makes no guarantees that cancelling a cancellable will result in the associated async operation terminating in an error. Specifically: if the (successful) result is already sent to the main context as an idle and waiting for dispatch then cancel() at this time will not be enough to fail it.

Talking to David and Alex about if GIO should make this guarantee or if we need to fix dbusmenu...

Trying to fix this in GLib: https://bugzilla.gnome.org/show_bug.cgi?id=672013

This bug was fixed in the package glib2.0 - 2.31.20-0ubuntu3

---------------
glib2.0 (2.31.20-0ubuntu3) precise; urgency=low

  * debian/patches/bugzilla_gdbus_use_reliable_cancellation.patch,
    debian/patches/bugzilla_reliable_cancellable.patch:
    - patches from GNOME bug #672013, should make gdbus cancellation
      reliable and fix dbusmenu lp: #953562
  * debian/libglib2.0-0.symbols:
    - updated for the new symbol
 -- Sebastien Bacher <email address hidden> Wed, 14 Mar 2012 11:45:37 +0100