At Thu, 27 Jun 2013 10:30:50 -0400, Forest Bond wrote:
Hi Takashi,
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.htm...
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 behavior?
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.
Ah, OK, this information was missing. In anyway, it'd be good if you can see how the whole config tree in memory looks when the segfault occurs. The NULL pointer alone doesn't mean a memory corruption like the previous case. We need a bit more overview.
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?
In general, the configuration space itself should be static, determined at the loading time.
Takashi