#390: pulse clients might abort if the pulseaudio server goes down
-----------------------+----------------------------------------------------
Reporter: mkretz | Owner: lennart
Type: defect | Status: new
Priority: normal | Milestone:
Component: libpulse | Severity: major
Resolution: | Keywords:
-----------------------+----------------------------------------------------
Comment (by lennart):
Replying to [comment:8 mkretz]:
> Breakpoint on ao_pulse_exit()? That wouldn't help much as that function
doesn't get called in this case at all. The function gets called if the
plugin is closed and destroyed by the application (or the Phonon backend
in this case), which is not the case here.
Are you sure it doesn't get called? That's the only place where the mutex
is invalidated.
> As I understand the problem, it's that xine's pulse output doesn't know
that the pulseaudio server is gone and all its pulse structures may not be
touched anymore. A forgiving pulse API would just silently let all calls
fail if the server is gone.
No. When the Pulse server goes away the pa client stays perfectly valid,
however it will have entered PA_CONTEXT_FAILED state, which will cause all
PA client functions return PA_ERR_BADSTATE as error code. It is perfectly
safe to call PA functions in that state -- they will all cleanly fail but
not cause an assert to be hit or suchlike.
The PA client API is perfectly forgiving when runtime errors (like a
connection termination happen). The only place where it is not forgiving
is when obvious programming errors happen -- i.e. when you pass invalid
memory and suchlike to PA.
Also, no PA data structure that is accessible to the applications is freed
by PA itself just like that. You will always need to trigger that from
your application, e.g. by calling a function like pa_context_unref() or
suchlike. If you continue using a pa_context object after you freed it
like that it's your own fault.
Finally, the error you triggered is not in the PA client, but in the event
loop abstraction. The event loop abstraction is completely independant
from any client code -- it is left completely untouched from connection
terminations.
Could you please run valgrind on this? Due to some reason pa_mutex_lock()
gets called with an invalid mutex. That might have two reasons: 1) the
mutex was never allocated in the first place. 2) it was already free at
time of calling.
In both cases valgrind should help us finding out what is going on.
--
Ticket URL: <http://www.pulseaudio.org/ticket/390#comment:9>
PulseAudio <http://pulseaudio.org/>
The PulseAudio Sound Server
_______________________________________________
pulseaudio-tickets mailing list
pulseaudio-tickets@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-tickets
