[pulseaudio-tickets] [PulseAudio] #390: pulse clients might abort if the pulseaudio server goes down

[PulseAudio]

#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