bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#9581: 24.0.50; dbus-unregister-object fails if service is nil


From: Julien Danjou
Subject: bug#9581: 24.0.50; dbus-unregister-object fails if service is nil
Date: Fri, 23 Sep 2011 01:01:17 +0200
User-agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.50 (gnu/linux)

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]