Re: espeakup stops speaking bookworm arm64

[Frank Carmickle]

Waking up this thread.

Samuel and others. Please let us know what we can do to help get this one 
sorted.

Thanks so much.
--FC


> On Jan 23, 2024, at 08:20, Geoff Shang  wrote:
> 
> On Sat, 6 Jan 2024, Samuel Thibault wrote:
> 
>> Geoff Shang, le jeu. 04 janv. 2024 15:04:22 +0200, a ecrit:
>>> I updated the core file at http://quitelikely.com/gcore
>> 
>> Thanks, that's indeed still the same situation: an alsa-lib mutex is
>> said to be held by a thread which is not executing alsa-lib code.
> 
> What's the next step then?
> 
> Cheers,
> Geoff.
> 

Re: espeakup stops speaking bookworm arm64

[Geoff Shang]

On Sat, 6 Jan 2024, Samuel Thibault wrote:


Geoff Shang, le jeu. 04 janv. 2024 15:04:22 +0200, a ecrit:

I updated the core file at http://quitelikely.com/gcore


Thanks, that's indeed still the same situation: an alsa-lib mutex is
said to be held by a thread which is not executing alsa-lib code.


What's the next step then?

Cheers,
Geoff.

Re: espeakup stops speaking bookworm arm64

[Frank Carmickle]

Samuel,

I know that I don't have anything interesting about my alsa config. I'd try 
your new espeak packages but I'm on arm64. My bookworm system was built from 
your modified debian installer.

I have just built a trixie arm64 machine today, if that would be more helpful.

Best,
--FC

Re: espeakup stops speaking bookworm arm64

[Geoff Shang]

On Sat, 6 Jan 2024, Samuel Thibault wrote:


Geoff Shang, le jeu. 04 janv. 2024 15:04:22 +0200, a ecrit:

I updated the core file at http://quitelikely.com/gcore


Thanks, that's indeed still the same situation: an alsa-lib mutex is
said to be held by a thread which is not executing alsa-lib code.

Are you perhaps running some particular alsa configuration?


No.  I just updated my Bullseye VM to Bookworm as documented in the 
release notes.  I've not touched the ALSA configuration.


HTH,
Geoff.

Re: espeakup stops speaking bookworm arm64

[Samuel Thibault]

Geoff Shang, le jeu. 04 janv. 2024 15:04:22 +0200, a ecrit:
> On Thu, 4 Jan 2024, Samuel Thibault wrote:
> 
> > Geoff Shang, le jeu. 04 janv. 2024 14:42:29 +0200, a ecrit:
> > > On Thu, 4 Jan 2024, Samuel Thibault wrote:
> > > 
> > > > Geoff Shang, le jeu. 04 janv. 2024 14:26:49 +0200, a ecrit:
> > > > > On Wed, 3 Jan 2024, Samuel Thibault wrote:
> > > > > 
> > > > > > 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.
> > > > > > {snip}
> > > > You can also as well just download the .deb file :)
> > > > 
> > > I see that you also have libespeak-ng1-dbgsym
> > > 
> > > Would you like me to install that too?
> > 
> > That'll be useful for gdb debugging, but not to check whether it works
> 
> It didn't.

Ok :/

> I updated the core file at http://quitelikely.com/gcore

Thanks, that's indeed still the same situation: an alsa-lib mutex is
said to be held by a thread which is not executing alsa-lib code.

Are you perhaps running some particular alsa configuration?

Samuel

Re: espeakup stops speaking bookworm arm64

[Geoff Shang]

On Thu, 4 Jan 2024, Samuel Thibault wrote:


Geoff Shang, le jeu. 04 janv. 2024 14:42:29 +0200, a ecrit:

On Thu, 4 Jan 2024, Samuel Thibault wrote:


Geoff Shang, le jeu. 04 janv. 2024 14:26:49 +0200, a ecrit:

On Wed, 3 Jan 2024, Samuel Thibault wrote:


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.
{snip}

You can also as well just download the .deb file :)


I see that you also have libespeak-ng1-dbgsym

Would you like me to install that too?


That'll be useful for gdb debugging, but not to check whether it works


It didn't.

I updated the core file at http://quitelikely.com/gcore

HTH,
Geoff.

Re: espeakup stops speaking bookworm arm64

[Samuel Thibault]

Geoff Shang, le jeu. 04 janv. 2024 14:42:29 +0200, a ecrit:
> On Thu, 4 Jan 2024, Samuel Thibault wrote:
> 
> > Geoff Shang, le jeu. 04 janv. 2024 14:26:49 +0200, a ecrit:
> > > On Wed, 3 Jan 2024, Samuel Thibault wrote:
> > > 
> > > > 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 looked at the ReadMe on your site and it said to run the following to
> > > import your apt key:
> > > 
> > > sudo apt-key adv --recv-keys --keyserver keyring.debian.org
> > > 900CB024B67931D40F82304BD0178C767D069EE6
> > > 
> > > But when I try, I get the following error:
> > > 
> > > Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d
> > > instead (see apt-key(8)).
> > > Executing: /tmp/apt-key-gpghome.N9pKWsZ2Uo/gpg.1.sh --recv-keys 
> > > --keyserver
> > > keyring.debian.org 900CB024B67931D40F82304BD0178C767D069EE6
> > > gpg: keyserver receive failed: Server indicated a failure
> > 
> > Uh? It does work here.
> 
> Interesting...
> 
> > > Is there another way that I can get your key?
> > 
> > Here it is, you can use apt-key add /tmp/sthibault.gpg
> 
> I just copied it into /etc/apt/trusted.gpg.d as instructed by apt-key(8).
> 
> > You can also as well just download the .deb file :)
> > 
> I see that you also have libespeak-ng1-dbgsym
> 
> Would you like me to install that too?

That'll be useful for gdb debugging, but not to check whether it works
:)

Samuel

Re: espeakup stops speaking bookworm arm64

[Geoff Shang]

On Thu, 4 Jan 2024, Geoff Shang wrote:


On Thu, 4 Jan 2024, Samuel Thibault wrote:


Geoff Shang, le jeu. 04 janv. 2024 14:26:49 +0200, a ecrit:

On Wed, 3 Jan 2024, Samuel Thibault wrote:


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.
[snip]

I see that you also have libespeak-ng1-dbgsym

Would you like me to install that too?

Never mind.  I saw that not installing it would remove my existing 
version, which is not surprising, so I went ahead and installed it.


Cheers,
Geoff.
\

Re: espeakup stops speaking bookworm arm64

[Geoff Shang]

On Thu, 4 Jan 2024, Samuel Thibault wrote:


Geoff Shang, le jeu. 04 janv. 2024 14:26:49 +0200, a ecrit:

On Wed, 3 Jan 2024, Samuel Thibault wrote:


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 looked at the ReadMe on your site and it said to run the following to
import your apt key:

sudo apt-key adv --recv-keys --keyserver keyring.debian.org
900CB024B67931D40F82304BD0178C767D069EE6

But when I try, I get the following error:

Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d
instead (see apt-key(8)).
Executing: /tmp/apt-key-gpghome.N9pKWsZ2Uo/gpg.1.sh --recv-keys --keyserver
keyring.debian.org 900CB024B67931D40F82304BD0178C767D069EE6
gpg: keyserver receive failed: Server indicated a failure


Uh? It does work here.


Interesting...


Is there another way that I can get your key?


Here it is, you can use apt-key add /tmp/sthibault.gpg


I just copied it into /etc/apt/trusted.gpg.d as instructed by apt-key(8).


You can also as well just download the .deb file :)


I see that you also have libespeak-ng1-dbgsym

Would you like me to install that too?

Cheers,
Geoff.

Re: espeakup stops speaking bookworm arm64

[Geoff Shang]

On Wed, 3 Jan 2024, Samuel Thibault wrote:


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?


I looked at the ReadMe on your site and it said to run the following to 
import your apt key:


sudo apt-key adv --recv-keys --keyserver keyring.debian.org 
900CB024B67931D40F82304BD0178C767D069EE6


But when I try, I get the following error:

Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d 
instead (see apt-key(8)).
Executing: /tmp/apt-key-gpghome.N9pKWsZ2Uo/gpg.1.sh --recv-keys 
--keyserver keyring.debian.org 900CB024B67931D40F82304BD0178C767D069EE6

gpg: keyserver receive failed: Server indicated a failure

Is there another way that I can get your key?

Cheers,
Geoff.

Re: espeakup stops speaking bookworm arm64

[Samuel Thibault]

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  
> > > > > wrote:
> > > > > > > #4  0x7fbedbb1a006 in snd_pcm_state () from 
> > > > > > > /lib/x86_64-linux-gnu/libasound.so.2
> > > > > > > No symbol table info available.
> > > > > > > #9  0x7fbedb7fd872 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

Re: espeakup stops speaking bookworm arm64

[Geoff Shang]

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  wrote:

#4  0x7fbedbb1a006 in snd_pcm_state () from 
/lib/x86_64-linux-gnu/libasound.so.2
No symbol table info available.
#9  0x7fbedb7fd872 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.

HTH,
Geoff.

Re: espeakup stops speaking bookworm arm64

[Samuel Thibault]

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  wrote:
> > > > > #4  0x7fbedbb1a006 in snd_pcm_state () from 
> > > > > /lib/x86_64-linux-gnu/libasound.so.2
> > > > > No symbol table info available.
> > > > > #9  0x7fbedb7fd872 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?

Thanks,
Samuel

Re: espeakup stops speaking bookworm arm64

[Geoff Shang]

On Sun, 31 Dec 2023, Samuel Thibault wrote:


Hello,

Frank Carmickle, le ven. 29 déc. 2023 20:46:21 -0500, a ecrit:

On Dec 29, 2023, at 15:54, Samuel Thibault  wrote:

#4  0x7fbedbb1a006 in snd_pcm_state () from 
/lib/x86_64-linux-gnu/libasound.so.2
No symbol table info available.
#9  0x7fbedb7fd872 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.

Cheers,
Geoff.
GNU gdb (Debian 13.1-3) 13.1
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/espeakup...
Reading symbols from 
/usr/lib/debug/.build-id/76/62ad26e5f970e59309a544f3864db114aa389e.debug...
Attaching to program: /usr/bin/espeakup, process 4406
[New LWP 4407]
[New LWP 4408]
[New LWP 4409]
[New LWP 4410]
[New LWP 4411]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
__futex_abstimed_wait_common64 (private=128, cancel=true, abstime=0x0, op=265, 
expected=4407, 
futex_word=0x7fdcb29fc990) at ./nptl/futex-internal.c:57

Thread 6 (Thread 0x7fdca3fff6c0 (LWP 4411) "espeakup"):
#0  __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, 
op=393, expected=0, futex_word=0x7fdcb3a0b1cc ) 
at ./nptl/futex-internal.c:57
sc_cancel_oldtype = 0
__arg6 = 
__arg3 = 
_a5 = 
_a2 = 
sc_ret = 
__arg4 = 
__arg1 = 
_a6 = 
_a3 = 
resultvar = 
__arg5 = 
__arg2 = 
_a4 = 
_a1 = 
#1  __futex_abstimed_wait_common (futex_word=futex_word@entry=0x7fdcb3a0b1cc 
, expected=expected@entry=0, 
clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0, 
cancel=cancel@entry=true) at ./nptl/futex-internal.c:87
err = 
clockbit = 256
op = 393
#2  0x7fdcb3619e0b in __GI___futex_abstimed_wait_cancelable64 
(futex_word=futex_word@entry=0x7fdcb3a0b1cc , 
expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, 
private=private@entry=0) at ./nptl/futex-internal.c:139
No locals.
#3  0x7fdcb361c468 in __pthread_cond_wait_common (abstime=0x0, clockid=0, 
mutex=0x7fdcb3a0b1e0 , cond=0x7fdcb3a0b1a0 
) at ./nptl/pthread_cond_wait.c:503
spin = 0
buffer = {__routine = 0x7fdcb361c1f0 <__condvar_cleanup_waiting>, __arg 
= 0x7fdca3ffedc0, __canceltype = 0, __prev = 0x0}
cbuffer = {wseq = 3103, cond = 0x7fdcb3a0b1a0 
, mutex = 0x7fdcb3a0b1e0 , private = 0}
err = 
g = 1
flags = 
g1_start = 
maxspin = 0
signals = 
result = 0
wseq = 3103
seq = 1551
private = 0
maxspin = 
err = 
result = 
wseq = 
g = 
seq = 
flags = 
private = 
signals = 
done = 
g1_start = 
spin = 
buffer = 
cbuffer = 
s = 
#4  ___pthread_cond_wait (cond=cond@entry=0x7fdcb3a0b1a0 
, mutex=mutex@entry=0x7fdcb3a0b1e0 ) at 
./nptl/pthread_cond_wait.c:618
No locals.
#5  0x7fdcb39b04cc in polling_thread (p=) at 
src/libespeak-ng/event.c:263
a_stop_is_required = false
__PRETTY_FUNCTION__ = "polling_thread"
#6  0x7fdcb361d044 in start_thread (arg=) at 
./nptl/pthread_create.c:442
ret = 
pd = 
out = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140585620993728, 
-928778118510472200, -136, 2, 140585853774560, 140585612603392, 
911159543697183736, 911196051988616184}, mask_was_saved = 0}}, priv = {pad = 
{0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = 
#7  0x7fdcb369d61c in clone3 () at 
../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
No locals.

Thread 5 (Thread 0x7fdcb0dfd6c0 (LWP 4410) "espeakup"):
#0  futex_wait (private=0, expected=2, futex_word=0x7fdca80568d0) at 
../sysdeps/nptl/futex-internal.h:146
__ret = -512
err = 
err = 
__ret = 
resultvar = 
__arg4 = 
__arg3 = 
__arg2 = 

Re: espeakup stops speaking bookworm arm64

[Samuel Thibault]

Hello,

Frank Carmickle, le ven. 29 déc. 2023 20:46:21 -0500, a ecrit:
> On Dec 29, 2023, at 15:54, Samuel Thibault  wrote:
> > Geoff Shang, le jeu. 21 déc. 2023 19:39:42 +0200, a ecrit:
> >> On Thu, 21 Dec 2023, Samuel Thibault wrote:
> > This is showing that it's alsa-lib which gets stuck. I tried to dive
> > into the source code, but I don't see yet how that can happen, a quick
> > review showed me that locking seems to be done properly. I'd probably
> > need a closer look since the hang *does* happen.
> > 
> >> #4  0x7fbedbb1a006 in snd_pcm_state () from 
> >> /lib/x86_64-linux-gnu/libasound.so.2
> >> No symbol table info available.
> >> #9  0x7fbedb7fd872 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.

Samuel

Re: espeakup stops speaking bookworm arm64

[Frank Carmickle]

On Dec 29, 2023, at 15:54, Samuel Thibault  wrote:
> 
> Hello,
> 
> Geoff Shang, le jeu. 21 déc. 2023 19:39:42 +0200, a ecrit:
>> On Thu, 21 Dec 2023, Samuel Thibault wrote:
>> 
>>> thread apply all bt full
>>> 
>>> :)
>> 
>> OK, you got it.
>> 
>> This produced 20 kb of output, so I've attached it.  Let me know if anyone
>> wants it included in the message instead.
> 
> Attached is completely fine, thanks a lot!
> 
> This is showing that it's alsa-lib which gets stuck. I tried to dive
> into the source code, but I don't see yet how that can happen, a quick
> review showed me that locking seems to be done properly. I'd probably
> need a closer look since the hang *does* happen.
> 
>> #4  0x7fbedbb1a006 in snd_pcm_state () from 
>> /lib/x86_64-linux-gnu/libasound.so.2
>> No symbol table info available.
>> #9  0x7fbedb7fd872 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. Please let us 
know if you need anything else. File attached.

Thanks so much, Samuel.

Happy New Year,
--FC


GNU gdb (Debian 13.1-3) 13.1
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "aarch64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/espeakup...
Reading symbols from 
/usr/lib/debug/.build-id/7c/ee622ad29eb52a84ecd41e5e9cb868d8d27eef.debug...
Attaching to program: /usr/bin/espeakup, process 92856
[New LWP 92857]
[New LWP 92858]
[New LWP 92859]
[New LWP 92860]
[New LWP 92861]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
0x99c4b694 in __futex_abstimed_wait_common64 (private=128, 
cancel=true, abstime=0x0, op=265, expected=92857, 
futex_word=0x98f5f1b0) at ./nptl/futex-internal.c:57

Thread 6 (Thread 0x96aff0e0 (LWP 92861) "espeakup"):
#0  0x99c4b694 in __futex_abstimed_wait_common64 (private=0, 
cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x99ff8c88 
) at ./nptl/futex-internal.c:57
_x3tmp = 0
_x0tmp = 281473265405064
_x0 = 281473265405064
_x3 = 0
_x4tmp = 0
_x1tmp = 393
_x1 = 393
_x4 = 0
_x5tmp = 4294967295
_x2tmp = 0
_x2 = 0
_x5 = 4294967295
_x8 = 98
_sys_result = 
sc_cancel_oldtype = 0
sc_ret = 
_sys_result = 
_x5tmp = 
_x4tmp = 
_x3tmp = 
_x2tmp = 
_x1tmp = 
_x0tmp = 
_x0 = 
_x1 = 
_x2 = 
_x3 = 
_x4 = 
_x5 = 
_x8 = 
#1  __futex_abstimed_wait_common (cancel=true, private=0, abstime=0x0, 
clockid=0, expected=0, futex_word=0x99ff8c88 
) at ./nptl/futex-internal.c:87
err = 
clockbit = 256
op = 393
err = 
clockbit = 
op = 
#2  __GI___futex_abstimed_wait_cancelable64 
(futex_word=futex_word@entry=0x99ff8c88 , 
expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, 
private=private@entry=0) at ./nptl/futex-internal.c:139
No locals.
#3  0x99c4e1d0 in __pthread_cond_wait_common (abstime=0x0, clockid=0, 
mutex=0x99ff8c28 , cond=0x99ff8c60 
) at ./nptl/pthread_cond_wait.c:503
spin = 0
buffer = {__routine = 0x99c4df14 <__condvar_cleanup_waiting>, __arg 
= 0x96afe828, __canceltype = -1711305632, __prev = 0x0}
cbuffer = {wseq = 5364, cond = 0x99ff8c60 
, mutex = 0x99ff8c28 , private = 0}
err = 
g = 0
flags = 
g1_start = 
maxspin = 0
signals = 
result = 0
wseq = 5364
seq = 2682
private = 0
maxspin = 
err = 
result = 
wseq = 
g = 
seq = 
flags = 
private = 
signals = 
done = 
g1_start = 
spin = 
buffer = 
cbuffer = 
s = 
#4  ___pthread_cond_wait (cond=cond@entry=0x99ff8c60 
, mutex=mutex@entry=0x99ff8c28 ) at 
./nptl/pthread_cond_wait.c:618
No locals.
#5  0x99f8f61c in polling_thread (p=) at 
src/libespeak-ng/event.c:263
a_stop_is_required = false
__PRETTY_FUNCTION__ = 

Re: espeakup stops speaking bookworm arm64

[Samuel Thibault]

Hello,

Geoff Shang, le jeu. 21 déc. 2023 19:39:42 +0200, a ecrit:
> On Thu, 21 Dec 2023, Samuel Thibault wrote:
> 
> > thread apply all bt full
> > 
> > :)
> 
> OK, you got it.
> 
> This produced 20 kb of output, so I've attached it.  Let me know if anyone
> wants it included in the message instead.

Attached is completely fine, thanks a lot!

This is showing that it's alsa-lib which gets stuck. I tried to dive
into the source code, but I don't see yet how that can happen, a quick
review showed me that locking seems to be done properly. I'd probably
need a closer look since the hang *does* happen.

> #4  0x7fbedbb1a006 in snd_pcm_state () from 
> /lib/x86_64-linux-gnu/libasound.so.2
> No symbol table info available.
> #9  0x7fbedb7fd872 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

Thanks,
Samuel

Re: espeakup stops speaking bookworm arm64

[Geoff Shang]

On Thu, 21 Dec 2023, Samuel Thibault wrote:


thread apply all bt full

:)


OK, you got it.

This produced 20 kb of output, so I've attached it.  Let me know if anyone 
wants it included in the message instead.


Because of the amount of output and the fact that I had to do it without 
speech, I set it up to run the command from the command line and to 
redirect the output.  The command was:


$ gdb -ex 'thread apply all bt full' /usr/bin/espeakup  >

BTW: I just noticed the subject line.  This is on amd64 (Debian running 
under VMWare Workstation Player on Windows 11 - yes I know...)


Cheers,
Geoff.
GNU gdb (Debian 13.1-3) 13.1
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/espeakup...
Reading symbols from 
/usr/lib/debug/.build-id/76/62ad26e5f970e59309a544f3864db114aa389e.debug...
Attaching to program: /usr/bin/espeakup, process 1474
[New LWP 1475]
[New LWP 1476]
[New LWP 1477]
[New LWP 1478]
[New LWP 1479]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
__futex_abstimed_wait_common64 (private=128, cancel=true, abstime=0x0, op=265, 
expected=1475, 
futex_word=0x7fbedaca3990) at ./nptl/futex-internal.c:57

Thread 6 (Thread 0x7fbecbfff6c0 (LWP 1479) "espeakup"):
#0  __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, 
op=393, expected=0, futex_word=0x7fbedbc791cc ) 
at ./nptl/futex-internal.c:57
sc_cancel_oldtype = 0
__arg6 = 
__arg3 = 
_a5 = 
_a2 = 
sc_ret = 
__arg4 = 
__arg1 = 
_a6 = 
_a3 = 
resultvar = 
__arg5 = 
__arg2 = 
_a4 = 
_a1 = 
#1  __futex_abstimed_wait_common (futex_word=futex_word@entry=0x7fbedbc791cc 
, expected=expected@entry=0, 
clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0, 
cancel=cancel@entry=true) at ./nptl/futex-internal.c:87
err = 
clockbit = 256
op = 393
#2  0x7fbedb887e0b in __GI___futex_abstimed_wait_cancelable64 
(futex_word=futex_word@entry=0x7fbedbc791cc , 
expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, 
private=private@entry=0) at ./nptl/futex-internal.c:139
No locals.
#3  0x7fbedb88a468 in __pthread_cond_wait_common (abstime=0x0, clockid=0, 
mutex=0x7fbedbc791e0 , cond=0x7fbedbc791a0 
) at ./nptl/pthread_cond_wait.c:503
spin = 0
buffer = {__routine = 0x7fbedb88a1f0 <__condvar_cleanup_waiting>, __arg 
= 0x7fbecbffedc0, __canceltype = 0, __prev = 0x0}
cbuffer = {wseq = 599, cond = 0x7fbedbc791a0 
, mutex = 0x7fbedbc791e0 , private = 0}
err = 
g = 1
flags = 
g1_start = 
maxspin = 0
signals = 
result = 0
wseq = 599
seq = 299
private = 0
maxspin = 
err = 
result = 
wseq = 
g = 
seq = 
flags = 
private = 
signals = 
done = 
g1_start = 
spin = 
buffer = 
cbuffer = 
s = 
#4  ___pthread_cond_wait (cond=cond@entry=0x7fbedbc791a0 
, mutex=mutex@entry=0x7fbedbc791e0 ) at 
./nptl/pthread_cond_wait.c:618
No locals.
#5  0x7fbedbc1e4cc in polling_thread (p=) at 
src/libespeak-ng/event.c:263
a_stop_is_required = false
__PRETTY_FUNCTION__ = "polling_thread"
#6  0x7fbedb88b044 in start_thread (arg=) at 
./nptl/pthread_create.c:442
ret = 
pd = 
out = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140457443063488, 
-3844386314597928019, -136, 2, 140457677941472, 140457434673152, 
3879966511456351149, 3879930324205335469}, mask_was_saved = 0}}, priv = {pad = 
{0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = 
#7  0x7fbedb90b61c in clone3 () at 
../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
No locals.

Thread 5 (Thread 0x7fbed8ffd6c0 (LWP 1478) "espeakup"):
#0  futex_wait (private=0, expected=2, futex_word=0x7fbed001ca00) at 
../sysdeps/nptl/futex-internal.h:146
__ret = -512
err = 
err = 
__ret = 
resultvar = 
__arg4 = 
__arg3 = 
__arg2 = 
__arg1 = 
_a4 = 
_a3 = 
_a2 = 
_a1 = 
#1  

Re: espeakup stops speaking bookworm arm64

[Samuel Thibault]

Geoff Shang, le jeu. 21 déc. 2023 18:50:52 +0200, a ecrit:
> On Thu, 21 Dec 2023, Samuel Thibault wrote:
> 
> > All we need now is the full
> > 
> > thread apply bt full
> > 
> > to get the most available information.
> 
> Earlier you said to use
> 
> thread apply all bt
> 
> Which do you want?

thread apply all bt full

:)

Samuel

Re: espeakup stops speaking bookworm arm64

[Geoff Shang]

On Thu, 21 Dec 2023, Samuel Thibault wrote:


All we need now is the full

thread apply bt full

to get the most available information.


Earlier you said to use

thread apply all bt

Which do you want?

Cheers,
Geoff.

Re: espeakup stops speaking bookworm arm64

[Samuel Thibault]

Frank Carmickle, le jeu. 21 déc. 2023 08:39:31 -0500, a ecrit:
> On Dec 20, 2023, at 18:34, Samuel Thibault  wrote:
> > 
> > James Addison, le mer. 20 déc. 2023 23:03:33 +, a ecrit:
> >> sthibault: do you think this could be related to
> >> https://github.com/linux-speakup/espeakup/pull/48 ?
> > 
> > Possibly. Testing would give a definite answer.
> > 
>  It took me a couple of goes, and I lost speech entirely both times (not 
>  sure why), but I got a trace.
>  
>  I'm not sure how helpful it is though.
>  
>  0x7f9de46bfda6 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
>  (gdb) bt
>  #0  0x7f9de46bfda6 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
>  #1  0x7f9de46c4b33 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
>  #2  0x5605c505e734 in main (argc=, argv=  out>)
>    at ../src/espeakup.c:229
> > 
> > To get useful information, the libc6-dbg package should be installed,
> > and this should be used:
> > 
> > thread apply all bt
> 
> I have installed
> 
> 
> 
> Reading symbols from /usr/bin/espeakup...
> Reading symbols from 
> /usr/lib/debug/.build-id/7c/ee622ad29eb52a84ecd41e5e9cb868d8d27eef.debug...
> Attaching to program: /usr/bin/espeakup, process 63456
> [New LWP 63457]
> [New LWP 63458]
> [New LWP 63459]
> [New LWP 63460]
> --Type  for more, q to quit, c to continue without paging--c
> [New LWP 63461]
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
> 0xb81bb694 in __futex_abstimed_wait_common64 (private=128,  
> cancel=true, abstime=0x0, op=265, expected=63457,  
> futex_word=0xb74cf1b0) at ./nptl/futex-internal.c:57
> 57 ./nptl/futex-internal.c: No such file or directory.
> (gdb) 
> 
> What am I missing?

It's completely fine that it doesn't have the .c files: I do have them
:) "__futex_abstimed_wait_common64" and "./nptl/futex-internal.c:57" are
the pieces of information that we do need, the details of the .c files
we can work by ourself, provided that we know the versions of the libc6,
libespeak-ng1, and espeakup packages. All we need now is the full

thread apply bt full

to get the most available information.

Samuel

Re: espeakup stops speaking bookworm arm64

[Frank Carmickle]

On Dec 20, 2023, at 18:34, Samuel Thibault  wrote:
> 
> James Addison, le mer. 20 déc. 2023 23:03:33 +, a ecrit:
>> sthibault: do you think this could be related to
>> https://github.com/linux-speakup/espeakup/pull/48 ?
> 
> Possibly. Testing would give a definite answer.
> 
 It took me a couple of goes, and I lost speech entirely both times (not 
 sure why), but I got a trace.
 
 I'm not sure how helpful it is though.
 
 0x7f9de46bfda6 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
 (gdb) bt
 #0  0x7f9de46bfda6 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
 #1  0x7f9de46c4b33 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
 #2  0x5605c505e734 in main (argc=, argv=)
   at ../src/espeakup.c:229
> 
> To get useful information, the libc6-dbg package should be installed,
> and this should be used:
> 
> thread apply all bt

I have installed



Reading symbols from /usr/bin/espeakup...
Reading symbols from 
/usr/lib/debug/.build-id/7c/ee622ad29eb52a84ecd41e5e9cb868d8d27eef.debug...
Attaching to program: /usr/bin/espeakup, process 63456
[New LWP 63457]
[New LWP 63458]
[New LWP 63459]
[New LWP 63460]
--Type  for more, q to quit, c to continue without paging--c
[New LWP 63461]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
0xb81bb694 in __futex_abstimed_wait_common64 (private=128,  
cancel=true, abstime=0x0, op=265, expected=63457,  
futex_word=0xb74cf1b0) at ./nptl/futex-internal.c:57
57 ./nptl/futex-internal.c: No such file or directory.
(gdb) 

What am I missing?

Thank you,
--FC

Re: espeakup stops speaking bookworm arm64

[Samuel Thibault]

James Addison, le mer. 20 déc. 2023 23:03:33 +, a ecrit:
> sthibault: do you think this could be related to
> https://github.com/linux-speakup/espeakup/pull/48 ?

Possibly. Testing would give a definite answer.

> > > It took me a couple of goes, and I lost speech entirely both times (not 
> > > sure why), but I got a trace.
> > >
> > > I'm not sure how helpful it is though.
> > >
> > > 0x7f9de46bfda6 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> > > (gdb) bt
> > > #0  0x7f9de46bfda6 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> > > #1  0x7f9de46c4b33 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> > > #2  0x5605c505e734 in main (argc=, argv= > > out>)
> > >at ../src/espeakup.c:229

To get useful information, the libc6-dbg package should be installed,
and this should be used:

thread apply all bt

Samuel

Re: espeakup stops speaking bookworm arm64

[James Addison]

sthibault: do you think this could be related to
https://github.com/linux-speakup/espeakup/pull/48 ?

(the reason for my guess: it is the only recent change within the
espeak_thread function - and a buffer-full / wait condition feels like
something that could occur semi-repeatably and could have edge cases)

Although the change from that pull request is not included in the
vanilla tarball of espeakup version 0.90 on GitHub, it is patched[1]
into Debian.

[1] - 
https://sources.debian.org/src/espeakup/1%3A0.90-13/debian/patches/flow_control/

On Wed, 20 Dec 2023 at 18:35, Frank Carmickle  wrote:
>
>
> > On Dec 20, 2023, at 13:21, Geoff Shang  wrote:
> >
> > On Tue, 28 Nov 2023, James Addison wrote:
> >
> >> To do that, the first step is to enable a sources.list entry for debug
> >> symbol packages, then to install the gdb and espeakup-dbgsym packages,
> >> and then after the espeakup process stops speaking, to attach the gdb
> >> debugger to locate where it got stuck by running: gdb
> >> /usr/bin/espeakup 
> >>
> >> If that works and you are provided with a (gdb) shell, you should be
> >> able to type the single word 'bt' and press enter to get a backtrace,
> >> and then copy and paste the results here.
> >
> > It took me a couple of goes, and I lost speech entirely both times (not 
> > sure why), but I got a trace.
> >
> > I'm not sure how helpful it is though.
> >
> > root@debian:~# gdb /usr/bin/espeakup 861
> > GNU gdb (Debian 13.1-3) 13.1
> > Copyright (C) 2023 Free Software Foundation, Inc.
> > License GPLv3+: GNU GPL version 3 or later 
> > 
> > This is free software: you are free to change and redistribute it.
> > There is NO WARRANTY, to the extent permitted by law.
> > Type "show copying" and "show warranty" for details.
> > This GDB was configured as "x86_64-linux-gnu".
> > Type "show configuration" for configuration details.
> > For bug reporting instructions, please see:
> > .
> > Find the GDB manual and other documentation resources online at:
> >.
> >
> > For help, type "help".
> > Type "apropos word" to search for commands related to "word"...
> > Reading symbols from /usr/bin/espeakup...
> > Reading symbols from 
> > /usr/lib/debug/.build-id/76/62ad26e5f970e59309a544f3864db114aa389e.debug...
> > Attaching to program: /usr/bin/espeakup, process 861
> > [New LWP 862]
> > [New LWP 863]
> > [New LWP 864]
> > [New LWP 865]
> > [New LWP 866]
> > [Thread debugging using libthread_db enabled]
> > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> > 0x7f9de46bfda6 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> > (gdb) bt
> > #0  0x7f9de46bfda6 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> > #1  0x7f9de46c4b33 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> > #2  0x5605c505e734 in main (argc=, argv=)
> >at ../src/espeakup.c:229
>
> Thanks for working on this.
>
> Just to document, line 229 of espeakup.c is
>
> pthread_join(signal_thread_id, NULL);
>
> --FC
>

Re: espeakup stops speaking bookworm arm64

[Frank Carmickle]

> On Dec 20, 2023, at 13:21, Geoff Shang  wrote:
> 
> On Tue, 28 Nov 2023, James Addison wrote:
> 
>> To do that, the first step is to enable a sources.list entry for debug
>> symbol packages, then to install the gdb and espeakup-dbgsym packages,
>> and then after the espeakup process stops speaking, to attach the gdb
>> debugger to locate where it got stuck by running: gdb
>> /usr/bin/espeakup 
>> 
>> If that works and you are provided with a (gdb) shell, you should be
>> able to type the single word 'bt' and press enter to get a backtrace,
>> and then copy and paste the results here.
> 
> It took me a couple of goes, and I lost speech entirely both times (not sure 
> why), but I got a trace.
> 
> I'm not sure how helpful it is though.
> 
> root@debian:~# gdb /usr/bin/espeakup 861
> GNU gdb (Debian 13.1-3) 13.1
> Copyright (C) 2023 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> Type "show copying" and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
>.
> 
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from /usr/bin/espeakup...
> Reading symbols from 
> /usr/lib/debug/.build-id/76/62ad26e5f970e59309a544f3864db114aa389e.debug...
> Attaching to program: /usr/bin/espeakup, process 861
> [New LWP 862]
> [New LWP 863]
> [New LWP 864]
> [New LWP 865]
> [New LWP 866]
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> 0x7f9de46bfda6 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> (gdb) bt
> #0  0x7f9de46bfda6 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> #1  0x7f9de46c4b33 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> #2  0x5605c505e734 in main (argc=, argv=)
>at ../src/espeakup.c:229

Thanks for working on this.

Just to document, line 229 of espeakup.c is

pthread_join(signal_thread_id, NULL);

--FC

Re: espeakup stops speaking bookworm arm64

[Geoff Shang]

On Tue, 28 Nov 2023, James Addison wrote:


To do that, the first step is to enable a sources.list entry for debug
symbol packages, then to install the gdb and espeakup-dbgsym packages,
and then after the espeakup process stops speaking, to attach the gdb
debugger to locate where it got stuck by running: gdb
/usr/bin/espeakup 

If that works and you are provided with a (gdb) shell, you should be
able to type the single word 'bt' and press enter to get a backtrace,
and then copy and paste the results here.


It took me a couple of goes, and I lost speech entirely both times (not 
sure why), but I got a trace.


I'm not sure how helpful it is though.

root@debian:~# gdb /usr/bin/espeakup 861
GNU gdb (Debian 13.1-3) 13.1
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/espeakup...
Reading symbols from 
/usr/lib/debug/.build-id/76/62ad26e5f970e59309a544f3864db114aa389e.debug...
Attaching to program: /usr/bin/espeakup, process 861
[New LWP 862]
[New LWP 863]
[New LWP 864]
[New LWP 865]
[New LWP 866]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x7f9de46bfda6 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0  0x7f9de46bfda6 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x7f9de46c4b33 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x5605c505e734 in main (argc=, argv=)
at ../src/espeakup.c:229


Cheers,
Geoff.

Re: espeakup stops speaking bookworm arm64

[James Addison]

On Mon, 27 Nov 2023 at 22:17,  wrote:
>
> Hi all,
> I don't know if my issue is the same as this or something different, but I am 
> experiencing Espeakup or Espeak crashing while using Vmware on one of the new 
> macs with the m2 processor.
>
> What url entries should Iput in my sources.list file to see if installing a 
> different package works better?

That issue does seem similar, thanks Tom.  I don't think there is
known fix yet, but there are some debug packages that you could
install if you have time to help track this down using gdb (a
debugging tool).

To do that, the first step is to enable a sources.list entry for debug
symbol packages, then to install the gdb and espeakup-dbgsym packages,
and then after the espeakup process stops speaking, to attach the gdb
debugger to locate where it got stuck by running: gdb
/usr/bin/espeakup 

If that works and you are provided with a (gdb) shell, you should be
able to type the single word 'bt' and press enter to get a backtrace,
and then copy and paste the results here.

The sources.list entry I added for Debian bookworm has the URI
http://deb.debian.org/debian-debug and the suite bookworm-debug, and
only includes packages from main.  More complete instructions are
available at https://wiki.debian.org/HowToGetABacktrace - note that I
don't think we should need to recompile any packages in this case,
because debug symbol packages should be available on arm64.

> -Original Message-
> From: James Addison 
> Sent: Monday, November 27, 2023 3:04 PM
> To: Geoff Shang 
> Cc: Frank Carmickle ; Debian Accessibility Team 
> ; ja...@jasonjgw.net
> Subject: Re: espeakup stops speaking bookworm arm64
>
> On Mon, 28 Aug 2023 at 10:46, Geoff Shang  wrote:
> >
> > On Mon, 24 Apr 2023, James Addison wrote:
> >
> > > Working towards a better backtrace is a good recommendation.  I'd also
> > > like to mention that there are existing Debian bookworm debug symbol
> > > packages available for both espeak and espeakup that can avoid the
> > > need to recompile from source.
> > >
> > > The packages are named 'espeak-dbgsym' and 'espeakup-dbgsym' and can
> > > be installed after enabling the bookworm-debug APT repository.
> >
> > I don't see espeakup-dbgsym in bookworm-debug.  I do see espeak-dbgsym,
> > however espeakup does not depend on espeak, it depends on libespeak,
> > actually libespeak-ng1.  There is also libespeak-ng1-dbgsym, but I'm not
> > sure if espeakup would use it if I installed it.
>
> I find both espeak-dbgsym and espeakup-dbgsym available in the package
> index today, after adding an apt sources.list entry for bookworm-debug
> - perhaps it could be worth checking for them again?
>
> Finding a way to cause the behaviour where espeakup stops talking
> would be useful to narrow in on the problem - I haven't been able to
> replicate it so far.
>
> (with apologies for this multi-month delayed reply.  I'll try not to
> replicate that)
>
>

Re: espeakup stops speaking bookworm arm64

[Frank Carmickle]

Hey Tom,


> On Nov 27, 2023, at 17:17,   
> wrote:
> 
> Hi all,
> I don't know if my issue is the same as this or something different, but I am 
> experiencing Espeakup or Espeak crashing while using Vmware on one of the new 
> macs with the m2 processor.

It's very much likely the same issue. I'm seeing on my m2 but with utm, which 
uses qemu for the virtualization.



> What url entries should Iput in my sources.list file to see if installing a 
> different package works better?

I don't think there are any. The question here is about weather or not the 
debug symbols packages help us trace the process when it locks up. I'll try 
again to run the debugger, but I don't think much has changed since I last 
check four months ago.

--FC

> 
> Tom
> 
> 
> -Original Message-
> From: James Addison  
> Sent: Monday, November 27, 2023 3:04 PM
> To: Geoff Shang 
> Cc: Frank Carmickle ; Debian Accessibility Team 
> ; ja...@jasonjgw.net
> Subject: Re: espeakup stops speaking bookworm arm64
> 
> On Mon, 28 Aug 2023 at 10:46, Geoff Shang  wrote:
>> 
>> On Mon, 24 Apr 2023, James Addison wrote:
>> 
>>> Working towards a better backtrace is a good recommendation.  I'd also
>>> like to mention that there are existing Debian bookworm debug symbol
>>> packages available for both espeak and espeakup that can avoid the
>>> need to recompile from source.
>>> 
>>> The packages are named 'espeak-dbgsym' and 'espeakup-dbgsym' and can
>>> be installed after enabling the bookworm-debug APT repository.
>> 
>> I don't see espeakup-dbgsym in bookworm-debug.  I do see espeak-dbgsym,
>> however espeakup does not depend on espeak, it depends on libespeak,
>> actually libespeak-ng1.  There is also libespeak-ng1-dbgsym, but I'm not
>> sure if espeakup would use it if I installed it.
> 
> I find both espeak-dbgsym and espeakup-dbgsym available in the package
> index today, after adding an apt sources.list entry for bookworm-debug
> - perhaps it could be worth checking for them again?
> 
> Finding a way to cause the behaviour where espeakup stops talking
> would be useful to narrow in on the problem - I haven't been able to
> replicate it so far.
> 
> (with apologies for this multi-month delayed reply.  I'll try not to
> replicate that)
> 
> 

RE: espeakup stops speaking bookworm arm64

[tommym2006]

Hi all,
I don't know if my issue is the same as this or something different, but I am 
experiencing Espeakup or Espeak crashing while using Vmware on one of the new 
macs with the m2 processor.

What url entries should Iput in my sources.list file to see if installing a 
different package works better?

Tom


-Original Message-
From: James Addison  
Sent: Monday, November 27, 2023 3:04 PM
To: Geoff Shang 
Cc: Frank Carmickle ; Debian Accessibility Team 
; ja...@jasonjgw.net
Subject: Re: espeakup stops speaking bookworm arm64

On Mon, 28 Aug 2023 at 10:46, Geoff Shang  wrote:
>
> On Mon, 24 Apr 2023, James Addison wrote:
>
> > Working towards a better backtrace is a good recommendation.  I'd also
> > like to mention that there are existing Debian bookworm debug symbol
> > packages available for both espeak and espeakup that can avoid the
> > need to recompile from source.
> >
> > The packages are named 'espeak-dbgsym' and 'espeakup-dbgsym' and can
> > be installed after enabling the bookworm-debug APT repository.
>
> I don't see espeakup-dbgsym in bookworm-debug.  I do see espeak-dbgsym,
> however espeakup does not depend on espeak, it depends on libespeak,
> actually libespeak-ng1.  There is also libespeak-ng1-dbgsym, but I'm not
> sure if espeakup would use it if I installed it.

I find both espeak-dbgsym and espeakup-dbgsym available in the package
index today, after adding an apt sources.list entry for bookworm-debug
- perhaps it could be worth checking for them again?

Finding a way to cause the behaviour where espeakup stops talking
would be useful to narrow in on the problem - I haven't been able to
replicate it so far.

(with apologies for this multi-month delayed reply.  I'll try not to
replicate that)

Re: espeakup stops speaking bookworm arm64

[James Addison]

On Mon, 28 Aug 2023 at 10:46, Geoff Shang  wrote:
>
> On Mon, 24 Apr 2023, James Addison wrote:
>
> > Working towards a better backtrace is a good recommendation.  I'd also
> > like to mention that there are existing Debian bookworm debug symbol
> > packages available for both espeak and espeakup that can avoid the
> > need to recompile from source.
> >
> > The packages are named 'espeak-dbgsym' and 'espeakup-dbgsym' and can
> > be installed after enabling the bookworm-debug APT repository.
>
> I don't see espeakup-dbgsym in bookworm-debug.  I do see espeak-dbgsym,
> however espeakup does not depend on espeak, it depends on libespeak,
> actually libespeak-ng1.  There is also libespeak-ng1-dbgsym, but I'm not
> sure if espeakup would use it if I installed it.

I find both espeak-dbgsym and espeakup-dbgsym available in the package
index today, after adding an apt sources.list entry for bookworm-debug
- perhaps it could be worth checking for them again?

Finding a way to cause the behaviour where espeakup stops talking
would be useful to narrow in on the problem - I haven't been able to
replicate it so far.

(with apologies for this multi-month delayed reply.  I'll try not to
replicate that)

Re: espeakup stops speaking bookworm arm64

[Geoff Shang]

On Tue, 29 Aug 2023, Chevelle wrote:

    I'm using AMD64, but sometimes I can find the PID for pipewire-pulse with 
'ps ax'.  Then enter

kill -SIGHUP 
Suddenly it will start working again.
It might be worth a try.


I'm not running pipewire.

This is a console-only VM running under VMWare Player 17 on Windows.

Cheers,
Geoff.

Re: espeakup stops speaking bookworm arm64

[Chevelle]

    I'm using AMD64, but sometimes I can find the PID for 
pipewire-pulse with 'ps ax'.  Then enter

kill -SIGHUP 
Suddenly it will start working again.
It might be worth a try.


On 8/28/23 05:46, Geoff Shang wrote:

On Mon, 24 Apr 2023, James Addison wrote:


Working towards a better backtrace is a good recommendation.  I'd also
like to mention that there are existing Debian bookworm debug symbol
packages available for both espeak and espeakup that can avoid the
need to recompile from source.

The packages are named 'espeak-dbgsym' and 'espeakup-dbgsym' and can
be installed after enabling the bookworm-debug APT repository.


I don't see espeakup-dbgsym in bookworm-debug.  I do see 
espeak-dbgsym, however espeakup does not depend on espeak, it depends 
on libespeak, actually libespeak-ng1.  There is also 
libespeak-ng1-dbgsym, but I'm not sure if espeakup would use it if I 
installed it.


Cheers,
Geoff.

Re: espeakup stops speaking bookworm arm64

[Geoff Shang]

On Mon, 24 Apr 2023, James Addison wrote:


Working towards a better backtrace is a good recommendation.  I'd also
like to mention that there are existing Debian bookworm debug symbol
packages available for both espeak and espeakup that can avoid the
need to recompile from source.

The packages are named 'espeak-dbgsym' and 'espeakup-dbgsym' and can
be installed after enabling the bookworm-debug APT repository.


I don't see espeakup-dbgsym in bookworm-debug.  I do see espeak-dbgsym, 
however espeakup does not depend on espeak, it depends on libespeak, 
actually libespeak-ng1.  There is also libespeak-ng1-dbgsym, but I'm not 
sure if espeakup would use it if I installed it.


Cheers,
Geoff.

Re: espeakup stops speaking bookworm arm64

[Chevelle]

    I have the AMD64 build of bookworm, but I have had it stop 
speaking.  Sometimes if I have a graphical session running, then switch 
to a speakup console, it is very slow to respond.  I wrote a simple bash 
script like this:


#!/usr/bin/bash

sleep 5

ls


I start that in the terminal with ORCA running then switch consoles to 
another session.  With that I can get some errors in the 'espeakup' 
debug log like this:


error: Device or resource busy
ALSA lib pcm_dmix.c:999:(snd_pcm_dmix_open) unable to open slave
error: Device or resource busy
ALSA lib pcm_dmix.c:999:(snd_pcm_dmix_open) unable to open slave
error: Device or resource busy
ALSA lib pcm_dmix.c:999:(snd_pcm_dmix_open) unable to open slave
error: Device or resource busy

Also if it is talking and you type something in the console you are in, 
it can't stop the speech.  Maybe I'm expecting to much, I'm not sure how 
it is designed to work.


Not sure if that helps.


On 8/18/23 12:39, Frank Carmickle wrote:

Greetings,

I've been living with this for the last sixish months, and it's annoying. I 
have a console where I can just up arrow and hit enter for

`killall -1 espeakup`

I would love to see this get fixed but I've gotten nowhere with debugging it.

I haven't tried Sam's recommendation of having a middle layer of pulseaudio or 
pipewire to keep the audio buffer always full with silence when it's not 
speaking. I spent so much time trying to get a working machine before, that 
I've not wanted to go back to work on it again for a bit. I'll probably get to 
it when the kids go back to school in a few weeks time.

I'll let you know if I find it to be of help.

--FC


On Aug 17, 2023, at 13:48, Geoff Shang  wrote:

Hello,

I just updated to Bookworm on my work VM running under VMWare 17 under Windows 
11 and am experiencing the same problem.

This was not happening under Bullseye.

The only other thing that I can add to what has already been described in this 
thread is that using conventional Debian methods to stop the espeakup process 
takes a long time.  Running espeakup in debug mode doesn't print anything to 
the console, and when I lose speech, I have to press control-backslash to kill 
it (control-c doesn't work).

I've only just seen the suggestion to test with the debug versions, which I 
will try at some point soon.

I'm running just in the console, no desktop environments.

BTW: I was just proofing this message and it died.  I was cursoring down 
through this email, so I wasn't reviewing by character this time.

Cheers,
Geoff.

Re: espeakup stops speaking bookworm arm64

[Frank Carmickle]

Greetings,

I've been living with this for the last sixish months, and it's annoying. I 
have a console where I can just up arrow and hit enter for

`killall -1 espeakup`

I would love to see this get fixed but I've gotten nowhere with debugging it.

I haven't tried Sam's recommendation of having a middle layer of pulseaudio or 
pipewire to keep the audio buffer always full with silence when it's not 
speaking. I spent so much time trying to get a working machine before, that 
I've not wanted to go back to work on it again for a bit. I'll probably get to 
it when the kids go back to school in a few weeks time.

I'll let you know if I find it to be of help.

--FC

> On Aug 17, 2023, at 13:48, Geoff Shang  wrote:
> 
> Hello,
> 
> I just updated to Bookworm on my work VM running under VMWare 17 under 
> Windows 11 and am experiencing the same problem.
> 
> This was not happening under Bullseye.
> 
> The only other thing that I can add to what has already been described in 
> this thread is that using conventional Debian methods to stop the espeakup 
> process takes a long time.  Running espeakup in debug mode doesn't print 
> anything to the console, and when I lose speech, I have to press 
> control-backslash to kill it (control-c doesn't work).
> 
> I've only just seen the suggestion to test with the debug versions, which I 
> will try at some point soon.
> 
> I'm running just in the console, no desktop environments.
> 
> BTW: I was just proofing this message and it died.  I was cursoring down 
> through this email, so I wasn't reviewing by character this time.
> 
> Cheers,
> Geoff.
> 
> 
> 

Re: espeakup stops speaking bookworm arm64

[Geoff Shang]

Hello,

I just updated to Bookworm on my work VM running under VMWare 17 under 
Windows 11 and am experiencing the same problem.


This was not happening under Bullseye.

The only other thing that I can add to what has already been described in 
this thread is that using conventional Debian methods to stop the espeakup 
process takes a long time.  Running espeakup in debug mode doesn't print 
anything to the console, and when I lose speech, I have to press 
control-backslash to kill it (control-c doesn't work).


I've only just seen the suggestion to test with the debug versions, which 
I will try at some point soon.


I'm running just in the console, no desktop environments.

BTW: I was just proofing this message and it died.  I was cursoring down 
through this email, so I wasn't reviewing by character this time.


Cheers,
Geoff.

Re: espeakup stops speaking bookworm arm64

[James Addison]

On Sun, 30 Apr 2023 at 01:10, James Addison  wrote:
>
> I don't have much to (bug)report here yet, but have begun using
> espeakup as a screen reader via Orca in GNOME.  CPU usage on the
> machine seemed relatively high, and at times text input became
> unresponsive (both in-browser, where both window scrolling and
> input-field text entry became unreliable).  The espeakup process also
> segfaulted once (this was over approximately 8 hours or so of
> continuous usage).

A missing ingredient from that soup of words: "(both in-browser, where
both window scrolling and input-field text entry became unreliable,
_and also within a gnome-terminal session_)."

(I think it's important to include that detail, because it suggests to
me that the cause of the high-resource-usage and/or input interaction
problems is not specific to one desktop application, and could be an
issue with Debian's espeakup/espeak-ng, and/or and their interaction
with the GNOME desktop.  CPU usage decreases to normal levels and
expected input behaviour is restored after screenreading is turned
off)

Re: espeakup stops speaking bookworm arm64

[James Addison]

On Tue, 25 Apr 2023 at 10:20, James Addison  wrote:
>
> On Mon, 24 Apr 2023 at 23:38, James Addison  wrote:
> >
> > On Apr 20, 2023, at 08:47:11, Jason White  wrote:
> > >
> > > Perhaps the following would also be worth trying:
> > >
> > > Rebuild Espeakup with compiler optimizations turned off and with debug 
> > > symbols enabled. This might produce a beter gdb backtrace if you connect 
> > > to the process when it's failing to generate output. You might also need 
> > > to rebuild Espeak, though.
> >
> > Working towards a better backtrace is a good recommendation.  I'd also
> > like to mention that there are existing Debian bookworm debug symbol
> > packages available for both espeak and espeakup that can avoid the
> > need to recompile from source.
>
> As a follow-up and partly for my own future reference: there is good
> documentation about retrieving backtraces on Debian systems at
> https://wiki.debian.org/HowToGetABacktrace

I don't have much to (bug)report here yet, but have begun using
espeakup as a screen reader via Orca in GNOME.  CPU usage on the
machine seemed relatively high, and at times text input became
unresponsive (both in-browser, where both window scrolling and
input-field text entry became unreliable).  The espeakup process also
segfaulted once (this was over approximately 8 hours or so of
continuous usage).

Re: espeakup stops speaking bookworm arm64

[James Addison]

On Mon, 24 Apr 2023 at 23:38, James Addison  wrote:
>
> On Apr 20, 2023, at 08:47:11, Jason White  wrote:
> >
> > Perhaps the following would also be worth trying:
> >
> > Rebuild Espeakup with compiler optimizations turned off and with debug 
> > symbols enabled. This might produce a beter gdb backtrace if you connect to 
> > the process when it's failing to generate output. You might also need to 
> > rebuild Espeak, though.
>
> Working towards a better backtrace is a good recommendation.  I'd also
> like to mention that there are existing Debian bookworm debug symbol
> packages available for both espeak and espeakup that can avoid the
> need to recompile from source.

As a follow-up and partly for my own future reference: there is good
documentation about retrieving backtraces on Debian systems at
https://wiki.debian.org/HowToGetABacktrace

Re: espeakup stops speaking bookworm arm64

[James Addison]

On Apr 20, 2023, at 08:47:11, Jason White  wrote:
>
> Perhaps the following would also be worth trying:
>
> Rebuild Espeakup with compiler optimizations turned off and with debug 
> symbols enabled. This might produce a beter gdb backtrace if you connect to 
> the process when it's failing to generate output. You might also need to 
> rebuild Espeak, though.

Working towards a better backtrace is a good recommendation.  I'd also
like to mention that there are existing Debian bookworm debug symbol
packages available for both espeak and espeakup that can avoid the
need to recompile from source.

The packages are named 'espeak-dbgsym' and 'espeakup-dbgsym' and can
be installed after enabling the bookworm-debug APT repository.  To do
that on my system, I opened the APT sources.list file, duplicated the
entry containing suite 'bookworm' for component 'main', and then
edited the duplicate to contain suite 'bookworm-debug' and to replace
URL ending '/debian' with '/debian-debug' instead.

(during the upgrade to bookworm, I converted the format of my APT
sources list, so I won't share the contents in this thread yet because
its format may be different to each of yours, a possible distraction,
but please let me know if it would be useful as a reference)

I've installed the packages and debug symbol packages on my machine,
so as we gather more ideas about how to make the problem reappear,
I'll be glad to join in tracing it down.

Re: espeakup stops speaking bookworm arm64

[Jason White]

Perhaps the following would also be worth trying:

Rebuild Espeakup with compiler optimizations turned off and with debug 
symbols enabled. This might produce a beter gdb backtrace if you connect 
to the process when it's failing to generate output. You might also need 
to rebuild Espeak, though.


On 15/4/23 10:55, Frank Carmickle wrote:

On Apr 15, 2023, at 08:25, James Addison  wrote:


If you're using systemd to manage services on those hosts: does the
system journal indicate any failures/restarts of the espeakup service?

No. Systemd only notices when I send the HUP signal.

Even when I run it in the foreground, and the speech stops, it reports nothing 
and continues operation.

--FC

Re: espeakup stops speaking bookworm arm64

[Frank Carmickle]

On Apr 15, 2023, at 08:25, James Addison  wrote:
> 
> 
> If you're using systemd to manage services on those hosts: does the
> system journal indicate any failures/restarts of the espeakup service?

No. Systemd only notices when I send the HUP signal.

Even when I run it in the foreground, and the speech stops, it reports nothing 
and continues operation.

--FC

Re: espeakup stops speaking bookworm arm64

[James Addison]

On Tue, 11 Apr 2023 at 18:27, Frank Carmickle  wrote:
>
> On Apr 11, 2023, at 13:19, James Addison  wrote:
> > That could be a useful clue.  Which of those three systems, if any,
> > are multi-processor?
>
> I suspected such a thing and so today I have been running the qemu arm64 
> system with a single core. Quite unfortunately it still stops speaking. All 
> of these systems are multiprocessor except for todays exercise with one core.

Hm, ok - well, it's good to know that the problem appears regardless
of single-core / multi-core.

If you're using systemd to manage services on those hosts: does the
system journal indicate any failures/restarts of the espeakup service?

Re: espeakup stops speaking bookworm arm64

[Sam Hartman]

> "Frank" == Frank Carmickle  writes:


>> You could play around with adding/subtracting pulseaudio/pipewire
>> within the guest and different approaches for how the emulator
>> talks to the host OS sound stack to explore whether this is the
>> case.

Frank> I have as minimal a setup as possible, no pulseaudio or
Frank> pipewire. Alsa reports the card as running at 48k and every
Frank> time the qemu starts the system it sets the guest to
Frank> 44.1k. We know then that qemu is resampling. I did start some
Frank> discussion about this on the qemu list.

Minimal is not always good here.
Something like pipewire or pulse is very likely to provide full buffers
and to provide silence if there's nothing to play until the device is
suspended.
Speech synthesizers are likely to just let the card underrun if they
have nothing to play.

I don't have specific recommendations on looking at interrupts.
If I wanted to test this hypothesis I'd write a small C program to try
and do what I thought espeak was doing and see if I could reproduce that
way.

That's kind of a pain, so I'd be more likely to see if I could get the
problem to go away by introducing pulse or pipewire, or adding or
removing dmix at the alsa level (although it's been a number of years
and I don't remember off the top of my head how to do that.)

--Sam

Re: espeakup stops speaking bookworm arm64

[Frank Carmickle]

On Apr 13, 2023, at 14:26, Sam Hartman  wrote:
> 
>> "Frank" == Frank Carmickle  writes:
> 
>Frank> Good day all, I'm pretty certain now that speech stops when
>Frank> doing screen review by character.
> 
>Frank> Does anyone know what would be different about this that
>Frank> would make this happen?
> 
> This is just a guess, but you might run into trouble if the amount of
> speech produced by one character is less than some sound fragment size.
> I.E. something is setting up to deliver interrupts when a buffer gets
> empty, but the buffer never gets full enough to trigger that.
> So a bug in the sound stack within the vm or a bug in the emulated sound
> card or a bug in the sound stack in the host OS
> or a bug in how the emulator interacts with the sound stack in the host
> os.
> By sound stack I include things like pulseaudio and pipewire.

Any recommendations on looking at interrupts?

> You could play around with adding/subtracting pulseaudio/pipewire within
> the guest and different approaches for how the emulator talks to the
> host OS sound stack to explore whether this is the case.

I have as minimal a setup as possible, no pulseaudio or pipewire. Alsa reports 
the card as running at 48k and every time the qemu starts the system it sets 
the guest to 44.1k. We know then that qemu is resampling. I did start some 
discussion about this on the qemu list.

Any tips on debugging alsa and the interface from espeak to it, and kernel to 
the emulated audio hardware?

> I want to stress that this is only my guess, although I have run into
> such problems over the years.

I'm guessing the problem is somewhere other than the emulated hardware to the 
kernel, as I see this behavior under the vmware hypervisor on x8664 as well as 
qemu arm64. When I can get some other hardware spun up, I can try qemu on x8664 
with Linux as the host instead of macOS.

Thanks for the discussion.
--FC

Re: espeakup stops speaking bookworm arm64

[Sam Hartman]

> "Frank" == Frank Carmickle  writes:

Frank> Good day all, I'm pretty certain now that speech stops when
Frank> doing screen review by character.

Frank> Does anyone know what would be different about this that
Frank> would make this happen?

This is just a guess, but you might run into trouble if the amount of
speech produced by one character is less than some sound fragment size.
I.E. something is setting up to deliver interrupts when a buffer gets
empty, but the buffer never gets full enough to trigger that.
So a bug in the sound stack within the vm or a bug in the emulated sound
card or a bug in the sound stack in the host OS
or a bug in how the emulator interacts with the sound stack in the host
os.
By sound stack I include things like pulseaudio and pipewire.

You could play around with adding/subtracting pulseaudio/pipewire within
the guest and different approaches for how the emulator talks to the
host OS sound stack to explore whether this is the case.

I want to stress that this is only my guess, although I have run into
such problems over the years.

Re: espeakup stops speaking bookworm arm64

[Frank Carmickle]

Good day all,

I'm pretty certain now that speech stops when doing screen review by character. 

Does anyone know what would be different about this that would make this happen?

I am on the latest, 0.90-13.

Thanks much,
--FC

Re: espeakup stops speaking bookworm arm64

[James Addison]

On Mon, 10 Apr 2023 at 21:07, Frank Carmickle  wrote:
>
> On Mar 30, 2023, at 10:49, James Addison  wrote:
> >
> > Yep, bugs with unpredictable timing can be particularly hard to track
> > down.  I noticed some references to process threads in one of your
> > previous messages (the acronym nptl for native posix thread library)
> > and also in the source code: that occurs to me as a possible area to
> > investigate, although I don't have clear suggestions on how we could
> > pinpoint thread-related timing issues.
>
>
> I have yet to correlate this to anything. I've begun looking in to the clock 
> that qemu provides. It seems as though there aren't any hardware clocks 
> accessible inside the VM on qemu hosted by macOS on aarch64. I'll report back.

Ok, thank you.

> I was seeing the on vmware on amd64 also.
>
> I have a bullseye machine running on bare metal that I haven't experienced 
> this issue with as of yet.

That could be a useful clue.  Which of those three systems, if any,
are multi-processor?

Re: espeakup stops speaking bookworm arm64

[Frank Carmickle]

On Apr 11, 2023, at 13:19, James Addison  wrote:
> That could be a useful clue.  Which of those three systems, if any,
> are multi-processor?

I suspected such a thing and so today I have been running the qemu arm64 system 
with a single core. Quite unfortunately it still stops speaking. All of these 
systems are multiprocessor except for todays exercise with one core.

--FC

Re: espeakup stops speaking bookworm arm64

[Frank Carmickle]

On Mar 30, 2023, at 10:49, James Addison  wrote:
> 
> Yep, bugs with unpredictable timing can be particularly hard to track
> down.  I noticed some references to process threads in one of your
> previous messages (the acronym nptl for native posix thread library)
> and also in the source code: that occurs to me as a possible area to
> investigate, although I don't have clear suggestions on how we could
> pinpoint thread-related timing issues.


I have yet to correlate this to anything. I've begun looking in to the clock 
that qemu provides. It seems as though there aren't any hardware clocks 
accessible inside the VM on qemu hosted by macOS on aarch64. I'll report back.

I was seeing the on vmware on amd64 also.

I have a bullseye machine running on bare metal that I haven't experienced this 
issue with as of yet.

--FC

Re: espeakup stops speaking bookworm arm64

[James Addison]

On Wed, 29 Mar 2023 at 20:14, Frank Carmickle  wrote:
> I guess you missed my followup message that it still does stop speaking. I'm 
> trying to notice as much as I can about the environment when it stops 
> speaking.

I did read that message - it seemed possible to me that configuring a
language could have altered the program's behaviour and reduced either
the number of errors, or their frequency.

> Maybe it's that I haven't tried the default language though. How would I find 
> that?

I'm not sure yet, but I do see some "udeb" scripts that might be
relevant and should be found in the following directory:
/usr/share/espeakup-udeb/

And in package version 1:0.90-11, I see a default voice of "en" in the
udeb start script, in at least three places.

There are some more recent package versions available, if you'd like
to try an upgrade.  It would be nice to figure out what the error's
cause is/was, though.

> I do find that it stops speaking mostly when I am navigating by character. It 
> seems as though navigating by character a bit slower is mostly when it 
> happens, but not all the time.
>
> It's super annoying that it can quit after a minute of use or many hours.

Yep, bugs with unpredictable timing can be particularly hard to track
down.  I noticed some references to process threads in one of your
previous messages (the acronym nptl for native posix thread library)
and also in the source code: that occurs to me as a possible area to
investigate, although I don't have clear suggestions on how we could
pinpoint thread-related timing issues.

Re: espeakup stops speaking bookworm arm64

[Frank Carmickle]

On Mar 29, 2023, at 17:55, James Addison  wrote:
> 
> Ok, that's cautiously promising.

I guess you missed my followup message that it still does stop speaking. I'm 
trying to notice as much as I can about the environment when it stops speaking.

I do find that it stops speaking mostly when I am navigating by character. It 
seems as though navigating by character a bit slower is mostly when it happens, 
but not all the time.

It's super annoying that it can quit after a minute of use or many hours.

Thanks,
--FC

Re: espeakup stops speaking bookworm arm64

[James Addison]

Ok, that's cautiously promising.

The next suggestion is maybe a bit annoying: try undoing or commenting-out
the language selection and checking whether the previous error-prone
behaviour returns.

I haven't been able to figure out why choosing a language in the config
file would make a difference yet, but if we can confirm that it definitely
does, then that's a useful clue.

On Wed, Mar 29, 2023, 20:14 Frank Carmickle  wrote:

> On Mar 29, 2023, at 14:17, Frank Carmickle  wrote:
> > That appears to be a very good question, as when I specify a language at
> all it doesn't seem to stop speaking. I hadn't even realized that the
> system didn't have a value in the config, /etc/default/espeakup. I'll keep
> pounding on it. As of the last few hours, I can not make it stop speaking
> once I have a language set. Maybe it's that I haven't tried the default
> language though. How would I find that?
>
> Spoke too soon . That time it took a very long time to replicate.
>
> Next?
>
> Thanks so much.
> --FC
>
>

Re: espeakup stops speaking bookworm arm64

[Frank Carmickle]

On Mar 29, 2023, at 14:17, Frank Carmickle  wrote:
> That appears to be a very good question, as when I specify a language at all 
> it doesn't seem to stop speaking. I hadn't even realized that the system 
> didn't have a value in the config, /etc/default/espeakup. I'll keep pounding 
> on it. As of the last few hours, I can not make it stop speaking once I have 
> a language set. Maybe it's that I haven't tried the default language though. 
> How would I find that?

Spoke too soon . That time it took a very long time to replicate.

Next?

Thanks so much.
--FC

Re: espeakup stops speaking bookworm arm64

[Frank Carmickle]

On Mar 29, 2023, at 10:23, James Addison  wrote:
> 
> Ok.  I'm not sure what to suggest in terms of build changes, so I'm wondering 
> about other command-line options before learning more about the build.
> 
> Does the problem occur when using different voices and languages?

That appears to be a very good question, as when I specify a language at all it 
doesn't seem to stop speaking. I hadn't even realized that the system didn't 
have a value in the config, /etc/default/espeakup. I'll keep pounding on it. As 
of the last few hours, I can not make it stop speaking once I have a language 
set. Maybe it's that I haven't tried the default language though. How would I 
find that?

Thanks much.
--FC

Re: espeakup stops speaking bookworm arm64

[James Addison]

Ok.  I'm not sure what to suggest in terms of build changes, so I'm
wondering about other command-line options before learning more about the
build.

Does the problem occur when using different voices and languages?

On Wed, Mar 29, 2023, 15:12 Frank Carmickle  wrote:

> Hello James,
>
> Thanks for this. It does not print any information when speaking stops.
> It does print that it received the hangup signal, which is what I sent to
> kill the process.
>
> What shall we add to a build to gain more insight?
>
> Thank you,
> --FC
>
>
>
>
>
> > On Mar 29, 2023, at 09:52, James Addison  wrote:
> >
> > On Mon, 20 Mar 2023 16:31:54 -0400, Frank wrote:
> >> I've reported this before, and I believe we had a fix for it. I just
> saw it happen again. This time it's bookworm arm64 . I can't remember what
> info was needed to track this down. Let me know what I can do please.
> >
> > Hi Frank,
> >
> > If you run the espeakup command with the debug flag ( --debug ) does
> > it produce any additional information before the process exits?
> >
> > Thanks,
> > James
>
>

Re: espeakup stops speaking bookworm arm64

[Frank Carmickle]

Hello James,

Thanks for this. It does not print any information when speaking stops.  It 
does print that it received the hangup signal, which is what I sent to kill the 
process.

What shall we add to a build to gain more insight?

Thank you,
--FC





> On Mar 29, 2023, at 09:52, James Addison  wrote:
> 
> On Mon, 20 Mar 2023 16:31:54 -0400, Frank wrote:
>> I've reported this before, and I believe we had a fix for it. I just saw it 
>> happen again. This time it's bookworm arm64 . I can't remember what info was 
>> needed to track this down. Let me know what I can do please.
> 
> Hi Frank,
> 
> If you run the espeakup command with the debug flag ( --debug ) does
> it produce any additional information before the process exits?
> 
> Thanks,
> James

Re: espeakup stops speaking bookworm arm64

[James Addison]

On Mon, 20 Mar 2023 16:31:54 -0400, Frank wrote:
> I've reported this before, and I believe we had a fix for it. I just saw it 
> happen again. This time it's bookworm arm64 . I can't remember what info was 
> needed to track this down. Let me know what I can do please.

Hi Frank,

If you run the espeakup command with the debug flag ( --debug ) does
it produce any additional information before the process exits?

Thanks,
James

Re: espeakup stops speaking bookworm arm64

[Samuel Thibault]

Hello,

Frank Carmickle, le lun. 20 mars 2023 16:31:54 -0400, a ecrit:
> I've reported this before, and I believe we had a fix for it.

I don't remember what issue you refer to.

Samuel

espeakup stops speaking bookworm arm64

[Frank Carmickle]

Hello all,

I've reported this before, and I believe we had a fix for it. I just saw it 
happen again. This time it's bookworm arm64 . I can't remember what info was 
needed to track this down. Let me know what I can do please.

Thanks
--FC