[alsa-devel] snd_device_name_hint segfaults

[Takashi Iwai]

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.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
> > 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