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

[Michael Albinus]

Julien Danjou <julien@danjou.info> writes:

>> I've played exactly this example (replacing "some.service" by
>> "org.gtk.Private.GduVolumeMonitor" in order to have an existing
>> service). No problem.
>
> Indeed. It works fine with org.gtk.Private.GduVolumeMonitor as service,
> but with "some.service" it fails. Why?

`dbus-register-signal' checks for the a valid service name, if it isn't
nil. Usually, "some.service" is not known; in my test
`dbus-register-signal' raises an error then.

How did you manage to register your signal with that service?

>> Could you apply (dbus-list-hash-table) before calling
>> `dbus-unregister-object', and show the result?
>
> Yeah. I start emacs-snapshot, then register then call
> `dbus-list-hash-table', it messages:
>
> (((:session "org.freedesktop.Notifications" "ActionInvoked")
>   (":1.129"
>    "org.freedesktop.Notifications" "/org/freedesktop/Notifications"
>    notifications-on-action-signal
>    
> "type='signal',interface='org.freedesktop.Notifications',member='ActionInvoked',sender=':1.129',path='/org/freedesktop/Notifications'"))
>  ((:session "org.freedesktop.Notifications" "NotificationClosed")
>   (":1.129" "org.freedesktop.Notifications"
>    "/org/freedesktop/Notifications" notifications-on-closed-signal
>    
> "type='signal',interface='org.freedesktop.Notifications',member='NotificationClosed',sender=':1.129',path='/org/freedesktop/Notifications'"))

These two entries show the correct match rule (the respective last element).

>  ((:session "org.gtk.Private.RemoteVolumeMonitor" "VolumeAdded")
>   (""
>    "some.service" "/org/gtk/Private/RemoteVolumeMonitor" identity
>    "‚
")))

This entry has a corrupted match rule. Again, which trick brings
`dbus-register-signal' to accept it? I must implement a counter-check
for this!

> Then I call unregister it yells:
> Debugger entered--Lisp error: (dbus-error "Unable to append argument" "\202
")
>   dbus-call-method(:session "org.freedesktop.DBus" "/org/freedesktop/DBus" 
> "org.freedesktop.DBus" "RemoveMatch" "\202
")
>
> Where the last string is obviously the same as I talked about above. :)

Which is the correct answer, because there isn't a valid match rule. I
could add a check for a valid match rule before sending the
"RemoveMatch" message, but I believe this is superfluous, because there
is exactly one place that match rule is appended. At this place, we must
prevent wrong values.

Best regards, Michael.