Dear Maintainer,

This bug was first reported in the Kali Linux installer, and it can be
reproduced in the Debian daily installer image [1].

The speech synthesis installation starts fine, but at some point,
there's no more sound. Therefore I open another console, type 'ps', I
can see that espeakup is not running. There's nothing in
/var/log/espeakup.log (the file is empty).

So I restart the process with additional debug argument:

  espeakup --alsa-volume -V en --debug

Back to the installer, the sound is back, I keep installing, until at
some point, it goes silent again. Back to the console, I can see that
espeakup crashed:

  espeakup: pcm.c:3237: snd_pcm_area_copy: Assertion `dst < src || dst >= src + bytes' failed.
  Aborted

It's fairly easy to reproduce, for me it crashes every time, although it
doesn't always crash at the same moment of the installation. The exact
moment when it crashes seems quite unpredictable.

Note that I'm running the iso in a QEMU VM on an up-to-date Debian Sid,
so that's qemu-system-x86 7.1+dfsg-2+b2 and linux-image-amd64 6.0.8-1,
in case it matters.

I'l try to debug further, but I'm not familiar with these low-level
bits. The assertion error happens in the alsa-lib source package (binary
package libasound2 is my guess), as you might have noticed. I really
have no clue how to debug that.

Best regards,

Arnaud

[1] https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd/

Hello,

Arnaud Rebillout, le lun. 21 nov. 2022 15:52:47 +0700, a ecrit:

Ouch!

Every detail can matter. Since it's in a vm, normally one should be able
to reproduce it, but it seems I can't. So please provide all details:

- how exactly you start the VM, notably which audio device do you use
- during installation, which choices do you make that depart from the
  default value (language, tasks, etc.)

Yes, I really doubt the bug is in espeakup (or pcaudiolib) itself since
these functions are really deep inside alsa, but we have to investigate
to be sure about it.

Samuel

My command is:

kvm -m 4G -cpu host \
-device e1000,netdev=net0 \
-netdev user,id=net0,hostfwd=tcp::10022-:22,hostfwd=tcp::3389-:3389 \
-device intel-hda \
-device hda-duplex \
-spice port=5930,disable-ticketing=on \
-device virtio-serial \
-device virtserialport,chardev=vdagent,name=com.redhat.spice.0 \
-chardev spicevmc,debug=0,id=vdagent,name=vdagent \
-vga qxl \
-virtfs local,mount_tag=home,path=/home/arno,security_model=none \
-drive file=debian-testing-amd64-netinst.img,format=raw \
-boot d -cdrom debian-testing-amd64-netinst.iso

I use remote-viewer and SPICE protocol to interact with the VM.

Maybe of interest, I see some errror messages in /var/log/syslog, after
I confirm the second screen. Here's a good chunk of logs for context,
the actual errors are the lines with "main-menu[527]: (process:xxxx):":

Nov 23 00:55:38 debconf: Setting debconf/language to en
Nov 23 00:55:38 main-menu[527]: INFO: Falling back to the package
description for brltty-udeb
Nov 23 00:55:38 main-menu[527]: INFO: Menu item 'localechooser' selected
Nov 23 00:55:40 debconf: Setting debconf/language to en
Nov 23 00:55:47 init: starting pid 507, tty '/dev/tty2': '-/bin/sh'
Nov 23 00:56:05 localechooser: info: Language = 'en'
Nov 23 00:56:05 localechooser: info: line=en;0;US;en_US.UTF-8;;console-setup
Nov 23 00:56:05 localechooser: info: Set debian-installer/language = 'en'
Nov 23 00:56:05 localechooser: info: Default country = 'US'
Nov 23 00:56:05 localechooser: info: Default locale = 'en_US.UTF-8'
Nov 23 00:56:05 localechooser: info: Set debian-installer/consoledisplay
= 'console-setup'
Nov 23 00:56:05 debconf: Setting debconf/language to en
Nov 23 00:56:08 localechooser: info: Set debian-installer/country = 'US'
Nov 23 00:56:08 localechooser: info: Set debian-installer/locale =
'en_US.UTF-8'
Nov 23 00:56:08 localechooser: info: System locale
(debian-installer/locale) = 'en_US.UTF-8'
Nov 23 00:56:08 main-menu[527]: (process:538): ls:
/usr/share/mbrola/en[1-9]/en[1-9]: No such file or directory
Nov 23 00:56:08 main-menu[527]: (process:538): sh: missing ]
Nov 23 00:56:08 main-menu[527]: (process:538): ls:
/usr/share/mbrola/en[1-9]/en[1-9]: No such file or directory
Nov 23 00:56:08 main-menu[527]: (process:538): sh: missing ]
Nov 23 00:56:08 main-menu[527]: INFO: Falling back to the package
description for brltty-udeb
Nov 23 00:56:08 main-menu[527]: INFO: Falling back to the package
description for brltty-udeb
Nov 23 00:56:08 main-menu[527]: INFO: Falling back to the package
description for brltty-udeb
Nov 23 00:56:08 main-menu[527]: INFO: Menu item 'brltty-udeb' selected
Nov 23 00:56:08 main-menu[527]: WARNING **: Unable to set title for
brltty-udeb.
Nov 23 00:56:08 main-menu[527]: INFO: Falling back to the package
description for brltty-udeb
Nov 23 00:56:08 main-menu[527]: INFO: Falling back to the package
description for brltty-udeb
Nov 23 00:56:08 main-menu[527]: INFO: Menu item 'espeakup-udeb' selected
Nov 23 00:56:10 main-menu[527]: (process:1753): ls:
/usr/share/mbrola/en[1-9]/en[1-9]: No such file or directory
Nov 23 00:56:10 main-menu[527]: (process:1753): sh: missing ]
Nov 23 00:56:10 main-menu[527]: INFO: Falling back to the package
description for brltty-udeb
Nov 23 00:56:10 main-menu[527]: INFO: Falling back to the package
description for brltty-udeb
Nov 23 00:56:10 main-menu[527]: INFO: Menu item 'console-setup-udeb'
selected

The errors related to mbrola and sh come from
debian/espeakup-udeb.restart in src:espeakup. I don't know if it's
relevant to the issue at hand though.

Just to confirm, I grabbed the debian-testing-amd64-netinst.iso from
today (2022-11-22) and I can confirm that I can still reproduce the issue.

Another interesting detail is that restarting espeakup makes it speaks
again, like if nothing happens. So I think it could be useful to have
something monitor the daemon and restart it in case it crashes. Would
make it more reliable overall, I suppose. Unfortunately I'm not familiar
with d-i and I couldn't even find from *where* espeakup is started (no
etc/init.d, no systemd).

Cheers,

Arnaud Rebillout, le mer. 23 nov. 2022 08:19:07 +0700, a ecrit:

Indeed (and debconf does that for its frontend so it's not unseen in d-i
:) ). I have now uploaded that, for a start.

There is no init or systemd so we start it by hand from
/lib/debian-installer/startup.d/S51espeakup, installed from
debian/espeakup-udeb.start

Samuel

Hello,

I was about to try to investigate, but I cannot reproduce it with the
daily image any more. It uses the new alsa-lib 1.2.8 upstream version,
so perhaps the bug was just fixed, could you also give it a try?

Samuel

I just grabbed the daily image. I can confirm that it comes with alsa
1.2.8, and also with espeakup 1:0.90-12 (ie. it contains your code to
restart espeakup).

On my side, espeakup keeps crashing, but it's restarted thanks to your
changes. I wouldn't have noticed the crashes if I didn't look at the logs.

The log file /var/log/espeakup.log shows that it's been restarted 3
times when I arrived at the tasksel screen.

Cheers,

Arnaud Rebillout, le lun. 05 déc. 2022 16:05:00 +0700, a ecrit:

Heh, obviously, didn't realize that my change was there and that I would
then not see the crash :D

Will have a better look next time I get around to it :)

Samuel

Hello,

For information, I have tried running the debian 13.1 install inside
vmware workstation 17.6.4, and couldn't reproduce the hang issue, so I'm
really unable to make any progress on this issue since I can't observe
and debug it directly.

Samuel