On 13 November 2012 19:20, Tanu Kaskinen <tanuk at iki.fi> wrote: > On Sun, 2012-11-11 at 12:21 -0500, Ian Malone wrote: >> 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. > > Thanks for digging into this. I should really test this myself. I'll try > to do that tomorrow. > Cool, thanks. If it's any help in reproducing it: I can get to this state quite easily with a single device available (in a VM) and using the test playback button in KDE's audio setup dialogue (using gstreamer->pulse backend). If quick after login or a pulseaudio -k I can see the services being created and disappearing normally, so it may be something to do with interaction with one of those. There's a suspend event during that process, I can post some -vvvv outputs from it if it's any help (with some logging added to reserve.c too). -- imalone http://ibmalone.blogspot.co.uk
