GNU bug report logs - #9581
24.0.50; dbus-unregister-object fails if service is nil

Previous Next

Full log

View this message in rfc822 format

From: Julien Danjou <julien <at> danjou.info>
To: 9581 <at> debbugs.gnu.org
Subject: bug#9581: 24.0.50; dbus-unregister-object fails if service is nil
Date: Fri, 23 Sep 2011 01:01:17 +0200

If you use `dbus-register-signal' with a nil SERVICE value, like:

      (dbus-register-signal :session nil
                            "/org/gtk/Private/RemoteVolumeMonitor"
                            "org.gtk.Private.RemoteVolumeMonitor" "VolumeAdded"
                            'identity)

This is valid and works fine. However, on unregister it fails:
Debugger entered--Lisp error: (dbus-error "Call to ReleaseName has wrong args (b, expected s)")
  dbus-call-method(:session "org.freedesktop.DBus" "/org/freedesktop/DBus" "org.freedesktop.DBus" "ReleaseName" nil)
  dbus-unregister-object(((:session "org.gtk.Private.RemoteVolumeMonitor" "VolumeAdded") (nil "/org/gtk/Private/RemoteVolumeMonitor" identity)))

Why does it fail? Because of the following code in
`dbus-unregister-object':

#+begin_src emacs-lisp
	(unless found
	  (dbus-call-method
	   bus dbus-service-dbus dbus-path-dbus dbus-interface-dbus
	   "ReleaseName" service))))
+end_src

And here service is… nil. Which is translated to a boolean (b) but
should be a string (s).

But honestly, I'm not sure what the good fix is. To me, this code is
totally wrong in such a case.

When using `dbus-register-signal', this happens:
1. the dbus_bus_add_match() function is called to add a match on the bus
2. the (match callback) pair is recorded into
   `dbus-registered-objets-table' 

This makes things work. When a signal happens, something is looking into
`dbus-registered-objets-table' and call the callback function.

But to stop listening for a signal, the function to use is
`dbus-unregister-object', and it is doing this:
1. remove the (match callback) pair from `dbus-registered-objets-table'
2. call ReleaseName on the service we were listening

While I agree on point 1., the point 2. is totally irrelevant in such a
case. There's no need to do such a thing, the name has never been
requested with RequestName before.

I think that:
- step 2 should be removed or another function should be created which
  does not send a ReleaseName
- dbus_bus_remove_match() should be used to remove the watch from the
  bus, which would be a lot cleaner.

-- 
Julien Danjou

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.