[alsa-devel] crashes in namehint

Harald Sitter sitter at kde.org
Thu Jan 31 17:06:56 CET 2013


I am working on kde multimedia and we are getting a considerable amount of
crash reports from x86 ubuntu and fedora users.


these crashes appear to be somewhat limited to x86 with only about 2
reports seeing this happen on x86_64. most of the reports suggest that it
happens at startup and in particular for applications that tend to query
ALSA devices shortly after startup (in fact, out of main() via a direct
call chain). there are 3 different reports of which a sigsev in strcpy and
sprintf seem most concerning. both appear in try_config() which was called
with a malformed `name` string.

now at least the sprintf and the strcpy crashes I can somewhat reliably
reproduce on kubuntu 12.10 x86 in a virtualbox vm using the command
'kcmshell4 phonon' with phonon-backend-vlc installed and selected as
and it appears that those are somehow related to how ubuntu does the
pulseaudio integration...

in /usr/share/alsa/alsa.conf all of alsa.conf.d/* is included, then there
is alsa.conf.d/pulse.conf which contains

> hook_func.pulse_load_if_running {
>  lib "libasound_module_conf_pulse.so"
>  func "conf_pulse_hook_load_if_running"
> }
> @hooks [
>  {
>  func pulse_load_if_running
>  files [
>  "/usr/share/alsa/pulse-alsa.conf"
>  ]
>  errors false
>  }
> ]

so they load /usr/share/alsa/pulse-alsa.conf after checking PA is running.
that file in turn contains the default pulse setup as seen in alsa-plugins

now with that lineup I can crash the kcmshell binary about 9/10 times with
the strcpy sigsev where name in try_config is 0.
if I replace the conditional load in pulse.conf with an explicit one (func
load) it crashes about half as often but with the sprintf sigsev in
try_config (name now being out-of-bounds rather than 0). if the content of
pulse-alsa.conf (i.e. the actual config) is copied into pulse.conf the
binary does not crash *at all*.

quite the mysterious problem. however, since the crash disappears entirely
when removing the second load (i.e. instead of
alsa.conf->alsa.conf.d/pulse.conf->pulse-alsa.conf one were to use
alsa.conf->alsa.conf.d/pulse.conf), I am lead to believe that this is
either a problem caused by the second level of loading in general or a
timing problem at large. most likely it is a combination of both where the
additional load() calls introduce sufficient overhead to trigger the timing

ideas/thoughts/fixes welcome :S



More information about the Alsa-devel mailing list