No subject
Fri Jul 31 19:24:53 CEST 2009
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
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]
More information about the Alsa-devel
mailing list