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

Ian Malone ibmalone at gmail.com
Sun Nov 25 04:43:47 PST 2012


On 24 November 2012 13:01, Tanu Kaskinen <tanuk at iki.fi> wrote:
> On Wed, 2012-11-21 at 03:04 -0500, Ian Malone wrote:
>> On 20 November 2012 14:01, Tanu Kaskinen <tanuk at iki.fi> wrote:
>> > On Tue, 2012-11-20 at 20:43 +0200, Tanu Kaskinen wrote:
>> >> On Tue, 2012-11-20 at 17:59 +0000, Ian Malone wrote:
>> >> > Thanks, I'll give it a go. I think handling the already_owner case in
>> >> > reserve.c as well might be worthwhile since there may be other ways to
>> >> > get to that state.
>> >>
>> >> I think it's a bug in the application if it calls rd_acquire for a
>> >> device that it already owns. An assertion might be the way to go. If not
>> >> an assertion, then at least an error.
>> >
>> > When writing that, I didn't realize that the current code already
>> > returns an error if dbus_bus_request_name() returns
>> > DBUS_REQUEST_NAME_REPLY_ALREADY_OWNER. I think that's a fine way of
>> > handling it, so in my opinion nothing needs to be done here.
>> >
>>
>> Okay I agree there is probably a more serious bug somewhere. I'll just
>> point out that the current response does not result in an error in
>> verbose output and that encountering that response results in removing
>> the reserve method and handlers, meaning if the service isn't broken
>> before it happens then it certainly is afterwards.
>
> Yes, if that error happens, the device reservation won't work, but the
> problem is not that the error is handled badly, the problem is that the
> error happens.

> That's probably not very useful when debugging this bug, though. When
> debugging this, I'd like you to add this assertion to rd_acquire():
>
> assert(k != DBUS_REQUEST_NAME_REPLY_ALREADY_OWNER);
>
> Then run pulseaudio in gdb and get a backtrace. Also, would it be
> possible for you try 2.99.2 (with the patch for reserve.c added)?
>

I'm attaching the backtrace for 2.1, without the reserve.c patch added
as otherwise it doesn't hit that condition.

2.99 with the reserve.c patch appears to work in that it drops the
DBus service correctly and the test playback from the KDE Audio Setup
works. 2.1 on the same setup does not release the device without the
reserve.c patch and with the reserve.c patch it drops the DBus service
but does not play the test sonud from audio setup.

-- 
imalone
http://ibmalone.blogspot.co.uk
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pulse-2.1-nocbpatch-assert.bt
Type: application/octet-stream
Size: 3192 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20121125/5861b425/attachment.obj>


More information about the pulseaudio-discuss mailing list