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.
Btw, error from rd_acquire() does cause a log message to be printed in
reserve-wrap.c:
pa_log_debug("Failed to acquire reservation lock on device '%s': %s", device_name, pa_cstrerror(-k));
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)?
> Moving on: 0001-reserve-Call-change_cb-only-if-there-actually-was-a-.patch
> I think we might be getting somewhere. This doesn't actually fix the
> problem, the service without a reservedevice1/audioN method still gets
> produced (this is the use case of trying KDE audio properties), but
> playback doesn't work, so it may be doing something related to the
> problem:
>
> pulseaudio -v output, no patch: http://pastebin.com/yfGEu1qx
> pulseaudio -v output, patched: http://pastebin.com/HkjSST4p
Note that you can add another "v" to get even more verbose output. I'm
not sure what I should look for in those logs. You said that "playback
doesn't work" - is that a good or a bad thing? Usually it's a bad thing,
but is the playback supposed to not work in this case due to the device
reservation? It looks like the alsa sink doesn't get unsuspended when
the last stream is created, so it looks like the device reservation is
doing its job (partially).
--
Tanu
