[alsa-devel] snd_device_name_hint segfaults
forest at alittletooquiet.net
Thu Jun 27 16:30:50 CEST 2013
Thanks for the reply.
On Thu, Jun 27, 2013 at 08:23:54AM +0200, Takashi Iwai wrote:
> At Wed, 26 Jun 2013 14:39:09 -0400, Forest Bond wrote:
> > I'm seeing segfaults with VLC similar to those reported here:
> > http://mailman.alsa-project.org/pipermail/alsa-devel/2013-January/059168.html
> > This is on Ubuntu 12.04 with the latest alsa-lib package (1.0.25-1ubuntu10.2)
> > and the following patches also applied:
> > * 2cfc8b9b44a8e493c41b3d63d5a00b306a18a5ed
> > snd_pcm_direct_parse_open_conf(): use thread-safe getgrnam_r()
> > * 44c1a623dd1fc9e831616b663bebc54ca98df994
> > Add snd_lib_error_set_local() to install a thread-local error handler.
> > * 25dbb102810b31c02358904d70d53c960fb0a10e
> > snd_device_name_hint(): do not change the global error handler.
> > * f49b2dc522a2564315c76d075203b15a39941e8a
> > snd_device_name_hint(): do not use global snd_config.
> > * 7f2b2c8c1650a1883b48abfcdb455138943854f9
> > conf: Fix a memory access violation resulting from improper error propogation
> > So I think there are still issues when calling snd_device_name_hint(-1, ...).
> > Here is the backtrace:
> > #0 0x003f0e78 in __strcpy_chk () from /lib/i386-linux-gnu/libc.so.6
> > #1 0x0625084b in strcpy (__src=0x0, __dest=0xb6025e80 "pcm.(null)") at /usr/include/i386-li
> > nux-gnu/bits/string3.h:105
> > #2 try_config (config=0xaf1c4df0, list=0xb52fe804, base=0x323e962 "pcm", name=0x0) at nameh
> > int.c:243
> > #3 0x06251bc5 in add_software_devices (list=0xb52fe804, config=0xaf1c4df0) at namehint.c:51
> > 2
> > #4 snd_device_name_hint (card=-1, iface=<optimized out>, hints=0xb52fe90c) at namehint.c:59
> > 1
> > #5 0x0323c9bb in GetDevices (obj=0xb6271700, item=0x0, prefs_dev=<optimized out>) at alsa.c
> > :721
> > #6 0x0323d4c0 in Probe (dev=0xb6011df8 "default", obj=0xb6271700) at alsa.c:161
> > #7 Open (obj=0xb6271700) at alsa.c:539
> > #8 0x0a6c73d0 in generic_start (func=0x323cd10, ap=0xb52fed98 "\273") at modules/modules.c:422
> > #9 0x0a6c7a3a in vlc_module_load (p_this=0xb6271700, psz_capability=0xa70b959 "audio output", psz_name=<optimized out>, b_strict=false,
> > probe=0xa6c73c0 <generic_start>) at modules/modules.c:347
> > #10 0x0a6c8002 in module_need (obj=0xb6271700, cap=0xa70b959 "audio output", name=0xa70d2bd "$aout", strict=false) at modules/modules.c:437
> > #11 0x0a6b1242 in aout_OutputNew (p_aout=0xb6271700, p_format=0xb52feeac) at audio_output/output.c:59
> > #12 0x0a6ad77f in aout_DecNew (p_aout=0xb6271700, p_format=0xb52feeac, p_replay_gain=0xaef02a14, p_request_vout=0xb52feed0)
> > at audio_output/dec.c:112
> > #13 0x0a67066e in aout_new_buffer (p_dec=0xaef02870, i_samples=1024) at input/decoder.c:2286
> > #14 0x0a672690 in decoder_NewAudioBuffer (p_decoder=0xaef02870, i_size=1024) at input/decoder.c:213
> > #15 0x04032f8c in DecodeBlock (p_dec=0xaef02870, pp_block=0xb52ff05c) at faad.c:464
> > #16 0x0a670891 in DecoderDecodeAudio (p_dec=0xaef02870, p_block=0xaef03000) at input/decoder.c:1291
> > #17 0x0a6716f5 in DecoderProcessAudio (b_flush=false, p_block=0xaef03000, p_dec=0xaef02870) at input/decoder.c:1936
> > #18 DecoderProcess (p_dec=0xaef02870, p_block=<optimized out>) at input/decoder.c:2059
> > #19 0x0a671959 in DecoderThread (p_data=0xaef02870) at input/decoder.c:938
> > #20 0x001fbd4c in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
> > #21 0x003ddace in clone () from /lib/i386-linux-gnu/libc.so.6
> > As a work around I will probably patch VLC to not call snd_device_name_hint this
> > way. I see this has been done for other applications:
> > http://code.google.com/p/chromium/issues/detail?id=95797
> > http://code.mythtv.org/trac/ticket/10809
> > But I wanted to try diagnosing the issue first. Thoughts?
> This isn't necessarily a bug due to the race like the previous case,
> but rather more simple one. For example, try the patch below.
> If this fixes, the question is how to trigger. Do you have any your
> own ~/.asoundrc or /etc/asound.conf? If yes, removing it changes the
Hm. I haven't tried your patch yet although I suspect that it would in fact fix
the crash. But I don't think the problem is that simple. I don't have a
.asoundrc or /etc/asound.conf configuration file. And the crashes don't happen
consistently on every run. In fact it usually takes a few hours of VLC starts
and stops to see the problem at all.
But I have a new theory. VLC should be using PulseAudio anyway, so I started
probing to figure out why it's initializing ALSA in the first place. Turns out
it will only do this when the PulseAudio module fails to initialize. One case
in which this happens is if PA is terminating at the same time VLC is starting.
I can manually trigger this by doing "pulseaudio -k && vlc ...".
You are probably aware that PA will automatically exit after being idle for some
time. I think we are playing media files on a schedule that happens to trigger
this scenario. So VLC starts up just as PA is quitting, and then the ALSA
module tries to enumerate available devices. What if some of the available
devices disappear during enumeration i.e. the PulseAudio ALSA plugin is
destroying its ALSA devices? Could that lead to this segfault?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: Digital signature
More information about the Alsa-devel