[pulseaudio-discuss] jackdbus module, pulse fails to conform on device reservation API

Ian Malone ibmalone at gmail.com
Sun Nov 11 09:21:19 PST 2012


On 10 November 2012 05:25, Ian Malone <ibmalone at gmail.com> wrote:
> On 9 November 2012 17:34, Tanu Kaskinen <tanuk at iki.fi> wrote:
>> On Tue, 2012-11-06 at 15:58 -0500, Ian Malone wrote:
>>> method call sender=:1.110 ->
>>> dest=org.freedesktop.ReserveDevice1.Audio1 serial=6
>>> path=/org/freedesktop/ReserveDevice1/Audio1;
>>> interface=org.freedesktop.ReserveDevice1; member=RequestRelease
>>>    int32 2147483647
>>> error sender=:1.35 -> dest=:1.110
>>> error_name=org.freedesktop.DBus.Error.UnknownMethod reply_serial=6
>>>    string "Method "RequestRelease" with signature "i" on interface
>>> "org.freedesktop.ReserveDevice1" doesn't exist
>>> "
>>

> If I hadn't seen it before I would say that that's exactly the message
> I expect a message framework (d-bus here) to generate when the method
> wasn't present. And indeed it is:
> $  dbus-send --session --print-reply --reply-timeout=2000
> --type=method_call --dest=org.freedesktop.ReserveDevice1.Audio1
> /org/freedesktop/ReserveDevice1/Audio1
> org.freedesktop.ReserveDevice1.RequestRelease int32:5
> Error org.freedesktop.DBus.Error.UnknownMethod: Method
> "RequestRelease" with signature "i" on interface
> "org.freedesktop.ReserveDevice1" doesn't exist
>
> I don't know how to capture this at the command line, so please see
> the d-feet shot of this:
>
> https://picasaweb.google.com/lh/photo/Mnty0Ul3ilCN_pB-ctJoD9MTjNZETYmyPJy0liipFm0?feat=directlink
>
> Audio1 is reserved (the service exists), but the object to request a
> release for Audio1 doesn't exist. Getting to this state was actually
> quite easy:
> 1. Start into KDE (pulse is set up as normal for Fedora and autostarted).
> 2. Start d-feet, you may catch the ReserveDevice1 services before they
> disappear, but wait till they do.
> 3. Open the KDE audio setup dialogue and test playback, this causes
> pulse to lock the capture device (hw:0 here) and the playback device
> (hw:1).
> 4. Look at the 'reserved' services. Audio1 is reserved, but can't be
> released because there's no object to provide the method.
>

=======
--- a/src/modules/reserve.c
+++ b/src/modules/reserve.c
@@ -409,6 +409,11 @@ int rd_acquire(
 		goto fail;
 	}

+	if (k == DBUS_REQUEST_NAME_REPLY_ALREADY_OWNER) {
+		// Potential leak?
+		goto success;
+	}
+
 	if (k == DBUS_REQUEST_NAME_REPLY_PRIMARY_OWNER)
 		goto success;
=======
It seems rd_acquire can get called while pulse still has the service
name (how? don't know. I've tried a return 0 there, but the object
path has already been unregistered at that point). Currently that
means it unregisters the filter handler and the object path for
releasedevice1, turning the service into a zombie until pulse is
killed. I've tried fixing this by changing the way d->owning is used,
but anything but the current setup seems to get stuck in a loop
between rd_callback, the filter_handler in reserve.c and rd_release,
possibly because unregistering the service triggers the filter_handler
with namelost somehow. Anyway, thou shalt check for possible return
values.

-- 
imalone
http://ibmalone.blogspot.co.uk


More information about the pulseaudio-discuss mailing list