Hello, Geoff Shang, le mar. 02 janv. 2024 15:33:20 +0200, a ecrit: > On Mon, 1 Jan 2024, Samuel Thibault wrote: > > > Hello, > > > > Geoff Shang, le lun. 01 janv. 2024 18:39:33 +0200, a ecrit: > > > On Sun, 31 Dec 2023, Samuel Thibault wrote: > > > > Frank Carmickle, le ven. 29 déc. 2023 20:46:21 -0500, a ecrit: > > > > > On Dec 29, 2023, at 15:54, Samuel Thibault <sthiba...@debian.org> > > > > > wrote: > > > > > > > #4 0x00007fbedbb1a006 in snd_pcm_state () from > > > > > > > /lib/x86_64-linux-gnu/libasound.so.2 > > > > > > > No symbol table info available. > > > > > > > #9 0x00007fbedb7fd872 in alsa_object_close () from > > > > > > > /lib/x86_64-linux-gnu/libpcaudio.so.0 > > > > > > > No symbol table info available. > > > > > > > > > > > > Would you be able to reproduce with these packages installed? > > > > > > > > > > > > libpcaudio0-dbgsym > > > > > > libasound2-dbgsym > > > > > > > > > > I have done, as Geoff has done, with these additional symbols. > > > > > > > > Was that really in the stuck case? Your traces don't show anything that > > > > seems to be stuck. > > > > > > Try this. > > > > Thanks! This is indeed the stuck condition I was looking for. > > > > I'm still baffled how we can end up in such a condition, I'd need to be > > able to perform more investigation. Perhaps you can trigger a core file > > generation by telling to gdb: > > > > generate-core-file /tmp/gcore > > > > and put it somewhere on the Internet for me to fetch it? > > http://quitelikely.com/gcore > > It's 300 mb.
Thanks! This confirms that "the impossible" has happened :) The alsa-lib lock reports a mutex being held by a thread that is not actually running alsa-lib functions. I however noticed that espeak-ng uses pcaudiolib without any locking, and pcaudiolib is definitely not threadsafe. On https://people.debian.org/~sthibault/tmp/bookworm-tmp I have put some libespeak updates (version 1.51+dfsg-10+pcaudioliblock) that add locking, could try to install libespeak-ng1 from there, and see if you can still reproduce the issue? Samuel
