Bug#589896: openarena: segfaults when using pulse-via-ALSA output and PulseAudio capture
Simon McVittie
smcv at debian.org
Fri Aug 20 18:22:39 UTC 2010
reassign 589896 libasound2
found 589896 1.0.23-1
affects 589896 openarena libportaudio2
thanks
On Fri, 20 Aug 2010 at 00:41:13 +0100, Simon McVittie wrote:
> I think I somewhat understand why this is failing now, but I don't know whose
> bug it is.
>
> > This one looks like the interesting one: it's the PA thread:
> >
> > > Thread 6 (Thread 0x7fffe359e710 (LWP 1508)):
> > > #0 0x00007fffe77369b0 in ?? ()
> > > No symbol table info available.
> > > #1 0x00007ffff574c9c7 in pa_command_request (pd=<value optimized out>,
> > > command=<value optimized out>, tag=<value optimized out>, t=0x270edf0,
> > > userdata=0x270a740) at pulse/stream.c:745
> >
> > Here's the code:
> >
> > 744 if (s->requested_bytes > 0 && s->write_callback)
> > 745 s->write_callback(s, (size_t) s->requested_bytes, s->write_userdata);
>
> The crash I'm getting is that the callbacks used by the PulseAudio plugins in
> openal-soft and alsa-lib are each in the corresponding plugin. It's possible
> to induce something (Pulse? ALSA? who knows) to dlclose() the plugin, causing
> it to drop out of OpenArena's address space, while the Pulse thread is still
> happily streaming data. The next time the Pulse thread invokes the callback,
> SIGSEGV ensues.
>
> So far I've only been able to reproduce this by setting the engine to
> use "ALSA Software" for output and the default "PulseAudio Capture" for
> input:
>
> openarena +set s_alDevice \"ALSA Software\" +set s_alCapture 1
>
> (the quoting is strange for the Quake 3 engine's benefit, do run it exactly
> as given!)
It turns out that the pulseaudio backends in src:openal-soft and
src:alsa-plugins don't dlclose anything until the stream has stopped, so
they're (probably) OK.
However, when OpenArena is trying to work out which capture device to use, it
loads/probes/unloads all the OpenAL backends, including PortAudio. When the
PortAudio backend is unloaded, the OpenAL portaudio backend calls
Pa_Terminate(), which (perhaps among other things) calls Terminate() in
pa_linux_alsa.c. The last thing done in Terminate() is
a call to snd_config_update_free_global(). This calls dlclose on the
ALSA pcm_pulse plugin, which is unloaded; cue SIGSEGV when the PulseAudio
worker thread tries to call pcm_pulse's callbacks.
There is an ALSA bug about this:
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2124
which is mentioned in a similar bug report:
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4426
Possible resolutions include:
* Declare snd_config_update_free_global to be buggy, and remove the call to
snd_dlobj_cache_cleanup (which appears to be a cleanup function that's
not safe to be called in an unknown context, like xmlCleanupParser [1]).
I think this is the real underlying bug, so I've reassigned this bug to ALSA.
* Treat snd_config_update_free_global() as an unsafe cleanup function,
and don't call it in PortAudio (in which case reassign to libportaudio2,
and hence the VoIP team).
* Treat Pa_Terminate() as an unsafe cleanup function, and don't call it in
OpenAL. I can make this change on behalf of the Games Team if it's considered
to be the best option.
* Decide that PortAudio support in OpenAL isn't useful for Debian, because
OpenAL already acts as an abstraction layer supporting OSS, ALSA and
PulseAudio, so the PortAudio backend just adds JACK support - which is
intended for pro-audio rather than gaming - plus more "moving parts" that
can go wrong. Again, I can make this change on behalf of the Games Team if
it's considered the best - I have a hacked version of libopenal1 which
refuses to load the PortAudio backend, and it does avoid this crash.
Thoughts from the ALSA/VoIP teams?
Thanks,
Simon
[1] http://0pointer.de/blog/projects/beware-of-xmlCleanupParser
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 793 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-voip-maintainers/attachments/20100820/5e72e50b/attachment.pgp>
More information about the Pkg-voip-maintainers
mailing list