[alsa-devel] [alsa-lib] Query regarding snd_config_update_free_global() and threads etc.
Hi there,
I've got a (hopefully quick) query about snd_config_update_free_global() and it's general thread safetyness.
I'm currently going insane on this bug: https://bugs.kde.org/show_bug.cgi?id=232068 which revolves around a bug manifested in snd_pcm_close() (or rather snd_pcm_ioplug_close()) when dealing with the ALSA->PulseAudio plugin.
_From what I can gather, this problem is related to a KDE module that is loaded into the library in question which does some alsa probing and ultimately calls snd_config_update_free_global() several times. The library itself then goes on to use GStreamer to do actual audio output. The crash then manifests itself prior to any sound actually being output.
I can reliably reproduce the machine on two machines (I don't have many at my disposal), but cannot reproduce on a third. The two I can reproduce it on are two and four core intel duo's. The one I cannot reproduce on is an older, single core machine. I am leaning towards some kind of thread safety issue.
In searching for similar problems, I found several references to similar crashes attributed to snd_dlobj_cache_cleanup() perhaps not being thread safe.
e.g.: https://bugzilla.redhat.com/show_bug.cgi?id=482797#c14 and http://osdir.com/ml/attachments/txtpisfDmzbcN.txt (and from that: https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2124 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589896 )
I've found that removing the calls to snd_config_update_free_global() avoid the issue. I'm not even sure they are needed, but all the same I wanted to discuss the core issue.
The MEMORY-LEAK file suggests that it should only be called after all snd_*_open() calls, but it doesn't indicate if this is just a recommendation or mandatory. Is the *only* purpose of this call to make valgrind happy? Or does it serve some other useful purpose too?
Col
On Mon, 23 Aug 2010, Colin Guthrie wrote:
Hi there,
I've got a (hopefully quick) query about snd_config_update_free_global() and it's general thread safetyness.
I'm currently going insane on this bug: https://bugs.kde.org/show_bug.cgi?id=232068 which revolves around a bug manifested in snd_pcm_close() (or rather snd_pcm_ioplug_close()) when dealing with the ALSA->PulseAudio plugin.
From what I can gather, this problem is related to a KDE module that is
loaded into the library in question which does some alsa probing and ultimately calls snd_config_update_free_global() several times. The library itself then goes on to use GStreamer to do actual audio output. The crash then manifests itself prior to any sound actually being output.
I can reliably reproduce the machine on two machines (I don't have many at my disposal), but cannot reproduce on a third. The two I can reproduce it on are two and four core intel duo's. The one I cannot reproduce on is an older, single core machine. I am leaning towards some kind of thread safety issue.
In searching for similar problems, I found several references to similar crashes attributed to snd_dlobj_cache_cleanup() perhaps not being thread safe.
I tried to work on snd_dlobj_cache issues. Please, could you test this patch?
http://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=91c9c8f1b85e69b4b...
Thanks, Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
'Twas brillig, and Jaroslav Kysela at 23/08/10 16:13 did gyre and gimble:
On Mon, 23 Aug 2010, Colin Guthrie wrote:
Hi there,
I've got a (hopefully quick) query about snd_config_update_free_global() and it's general thread safetyness.
I'm currently going insane on this bug: https://bugs.kde.org/show_bug.cgi?id=232068 which revolves around a bug manifested in snd_pcm_close() (or rather snd_pcm_ioplug_close()) when dealing with the ALSA->PulseAudio plugin.
From what I can gather, this problem is related to a KDE module that is
loaded into the library in question which does some alsa probing and ultimately calls snd_config_update_free_global() several times. The library itself then goes on to use GStreamer to do actual audio output. The crash then manifests itself prior to any sound actually being output.
I can reliably reproduce the machine on two machines (I don't have many at my disposal), but cannot reproduce on a third. The two I can reproduce it on are two and four core intel duo's. The one I cannot reproduce on is an older, single core machine. I am leaning towards some kind of thread safety issue.
In searching for similar problems, I found several references to similar crashes attributed to snd_dlobj_cache_cleanup() perhaps not being thread safe.
I tried to work on snd_dlobj_cache issues. Please, could you test this patch?
http://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=91c9c8f1b85e69b4b...
Sure, will try and do so this evening and report back. Thanks!
Col
'Twas brillig, and Colin Guthrie at 23/08/10 16:49 did gyre and gimble:
'Twas brillig, and Jaroslav Kysela at 23/08/10 16:13 did gyre and gimble:
On Mon, 23 Aug 2010, Colin Guthrie wrote:
Hi there,
I've got a (hopefully quick) query about snd_config_update_free_global() and it's general thread safetyness.
I'm currently going insane on this bug: https://bugs.kde.org/show_bug.cgi?id=232068 which revolves around a bug manifested in snd_pcm_close() (or rather snd_pcm_ioplug_close()) when dealing with the ALSA->PulseAudio plugin.
From what I can gather, this problem is related to a KDE module that is
loaded into the library in question which does some alsa probing and ultimately calls snd_config_update_free_global() several times. The library itself then goes on to use GStreamer to do actual audio output. The crash then manifests itself prior to any sound actually being output.
I can reliably reproduce the machine on two machines (I don't have many at my disposal), but cannot reproduce on a third. The two I can reproduce it on are two and four core intel duo's. The one I cannot reproduce on is an older, single core machine. I am leaning towards some kind of thread safety issue.
In searching for similar problems, I found several references to similar crashes attributed to snd_dlobj_cache_cleanup() perhaps not being thread safe.
I tried to work on snd_dlobj_cache issues. Please, could you test this patch?
http://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=91c9c8f1b85e69b4b...
Sure, will try and do so this evening and report back. Thanks!
That patch (along with 09879a4bb58199f64abcb8df506f917c8efc2383: pcm: add defaults.pcm.minperiodtime parsing - just to avoid conflicts) on top of 1.0.23 seems to fix the easily reproducible crash case for me. \o/
Awesome. Thanks!
Col
participants (2)
-
Colin Guthrie -
Jaroslav Kysela