aloha,
I am working on kde multimedia and we are getting a considerable amount of crash reports from x86 ubuntu and fedora users.
https://bugs.kde.org/show_bug.cgi?id=268185 http://notes.kde.org/alsa-bugs
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 default. 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 [1]
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 problem.
ideas/thoughts/fixes welcome :S
HS
[1] http://git.alsa-project.org/?p=alsa-plugins.git;a=blob;f=pulse/99-pulseaudio...