espeakup 0.90+ random freezes

[ctirad]

I have stability issues on my gentoo based system with espekup 0.90 and espeak-ng on amd64 platform, plenty of RAM, console only. The espeakup randomly crashes (with "killed" debug out) or freezes (daemon stop speech but won't exit). Tested on multiple machines. Also tried latest git version and latest git espeakup-ng git. No difference. What can I try?

[sthibaul]

You can run with core generation enabled:

ulimit -c unlimited

and get the backtrace from gdb:

gdb /usr/bin/espeakup core
gdb> thread apply all bt full

and post that.

Make sure to have debugging symbols available for the backtrace to be informative. I don't know how gentoo provides debugging symbols.

[ctirad]

Thanks. I included gdb and espekup with symbol to my system. I wasn't able to reproduce a full crash, so far, just a couple of freezes. Unfortunately a freezed espeakup does not produce any core dump, it's more like an internal deadlock where it stops talking and reacting to SIGINT signal. It also blocks dmesg command output after a couple of pages. Interesting.

I also noticed, that espekup started without parameters (default english) seems to be pretty stable. With "-V czech" (my native language) it freezes usually in a couple of minutes.

[sthibaul]

Unfortunately a freezed espeakup does not produce any core dump

You can trigger a core dump by sending SIGQUIT

I also noticed, that espekup started without parameters (default english) seems to be pretty stable. With "-V czech" (my native language) it freezes usually in a couple of minutes.

That may then be a problem with espeak-ng's czech support :/

[JanuszChmiel]

Dear elite C developers and users,
The situation is really not easy. The problem is, that Arch Linux which can be perfectly installed by using Archinstall Python scripts can be only reliably installed by a visually impaired screen reader user with Speakup only. I AM also occuring random freezes of Espeakup when I Am running official ArchLinux installation CD.
I will try to kill Espeakup and re run it without default option to use English language. The very interesting fact is, that Espeakup work like A charm for many years when running from Debian Net Inst installation CD. Espeakup never crash randomly even if I choose Czech language from Debian installer choices list.
I do not know, if there is not An complex Alsa driver related or kernel related issue when running Arch Linux. Using different USB sound hardware is not A solution, because unfortunately using Arch Linux install CD is not possible to use with SUSB audiod evices. Some configuration is not enabled by default, sad reality. But some Alsa elite Arch Linux developers know very wll The reason why they did not enabled USB devices in The arch Linux installation CD by default, may be some security reason in todays times, it is interesting. But for finding out why Espeakup randomly crashes, try to analyse Debian Netinnst CDS and Alsa configuration and kernel.

[JanuszChmiel]

Here are my new findings.
Random crashes may be solved if you will use some virtualisation software which emulate BIOS, not UEFI. As a result, target installation harddisk will not be UEFI compatible thought.
I have tried Fedora 39 with Virt-manager which support USB-redirect module. If I executed ArchLinux installation image, it did not produce sound output at all if firmware is set to UEFI.
But BIOS firmware support sound and no crashes.

[sthibaul]

So this really looks to me like an issue in the alsa stack.

[fcarmickle]

Because I am running on arm64 I pretty much need to use uefi. I could try booting the kernel directly with qemu, but that means manual configuration every time a kernel update happens, inside the host. I tried changing the sound device in the guest to virtio-snd-pci, which had extreme latency and was very choppy. I also tried virtio-snd, and alsa doesn't seem to think that sound hardware exists at all in that case. I then tried ens1370, which Debian's kernel no longer compiles support for. What can we do to engage alsa and or qemu developers about the ich6/ich9 issues? What info can I gather to show them where the problem is? Thank you. Best, --FC