Bug: preproc crashes with coredump

[StarPet]

I've moved to openSUSE Leap 15.3. Here prepoc does not work anymore. Though, in the earlier 15.2 and 15.1 I installed mbrola via RPM. Now - to fix this issue - I used these sources and compiled it as instructed in your README.md

I'm not a cpp programmer (more plain C, python, bash, php etc.) but from my understanding of the preproc source it should spit out a usage message if here is no argument supplied. However it cores.

homesrv:~/git/txt2pho # ./preproc Speicherzugriffsfehler (Speicherabzug geschrieben)

So, I tried to debug it and saw:

homesrv:~/git/txt2pho # gdb ./preproc ... (gdb) run Starting program: /root/git/txt2pho/preproc Missing separate debuginfos, use: zypper install glibc-debuginfo-2.31-7.30.x86_64

Program received signal SIGSEGV, Segmentation fault. 0x00007ffff722fca2 in __strcpy_avx2 () from /lib64/libc.so.6

Looking at the source again I find the line: PPInput ip("-", "()&\%") ; Which i suspect as the /tmp/preproc974913.log exists and is empty. However, this seems to be a cpp class instance creation which I have no idea what might go wrong there.

I've moved the line back to a later time - as ip is referenced later - and now I'll get the usage as expected:

homesrv:~/git/txt2pho # ./preproc Usage: preproc Rules-File | read from stdin, write to stdout

Any ideas why this instance creation fails?

[GHPS]

Thanks for the bug report!

Here prepoc does not work anymore.

Did you take the latest version of preproc - including https://github.com/GHPS/txt2pho/commit/2d1282c31ff3c76d0445dabd343e7a831368bddf?

Just today I fixed an issues in the preproc caused by an uninitialized string...

[StarPet]

Just today I fixed an issues in the preproc caused by an uninitialized string... What a coincidence. :D Great. Your fix worked fine. My homeautomation is talking again. I've used espeak as a workaround but it does not sound nearly as good. Thanks!

[GHPS]

Your fix worked fine.

That sound good. The bug must have been there for ages and I'm wondering why the preproc didn't crash years ago...

My homeautomation is talking again.

May I ask which automation system you use?

[StarPet]

That sound good. The bug must have been there for ages and I'm wondering why the preproc didn't crash years ago...

Jep... I copied "older" binaries to get it to work. Now that is fixed.

May I ask which automation system you use?

Initially - around late 2005 - I was using FHEM and even participated in some development there. But I don't like pearl. I quickly started my own set of tools and scripts. Some C-Programs, mostly bash-scripts and about three years ago I've started to move some tools to python. So, nothing from stock. All handcrafted. ;-) Approx 73000 lines of code. I only started last week to upload some stuff here onto github. However, I will not upload all of it. Just tools that might be of use for others. I have a small house with several Raspberry PIs with USB-Speakers and motion sensors via deConz (zigbee) that tells my homeautomation where I am. So, it can turn on lights etc and talk to me via mbrola. I use it as a reminder for my laundry, to wake me up with current weather and news lines (via XML from tagesschau.de) etc.

[GHPS]

All handcrafted. ;-) Approx 73000 lines of code.

Wow - I'm impressed!

Some C-Programs, mostly bash-scripts and about three years ago I've started to move some tools to python.

Yes - some tasks can be solved with Python much easier. For example I've started to reimplement preproc in Python. In the long term this could replace the c-Version in this repro since the development options for this are limited.

Thanks for your support of txt2pho!

[richardweinberger]

Is this fix part of a release? I'm facing the same(?) problem in a recent OpenSUSE system. I fear disto packagers never saw this fix.

[StarPet]

Is this fix part of a release? I'm facing the same(?) problem in a recent OpenSUSE system. I fear disto packagers never saw this fix.

You may open a bug at https://bugzilla.opensuse.org/ or at pacman (depending on where you pull the RPM packages from). They will probably have issues with this as their package (mbrola) contains much more and they would have to replace preproc within that package. I didn't bother to open a bugzilla at SUSE but used the code from here for my usage. That spared me the hassle of another discussion with SUSE support. ;-)

[richardweinberger]

Is this fix part of a release? I'm facing the same(?) problem in a recent OpenSUSE system. I fear disto packagers never saw this fix.

You may open a bug at https://bugzilla.opensuse.org/ or at pacman (depending on where you pull the RPM packages from). They will probably have issues with this as their package (mbrola) contains much more and they would have to replace preproc within that package. I didn't bother to open a bugzilla at SUSE but used the code from here for my usage. That spared me the hassle of another discussion with SUSE support. ;-)

This is not an answer to my question. Unless I'm mistaken, please correct me if I'm wrong, this project does not make releases. So how are distribution package maintainers supposed to know when to update their sources?

[GHPS]

@richardweinberger: Thanks for reporting that this bug still exists in the wild - and for the subsequent debate.

Initially I was surprised by the sheer unlikeliness of this issue: @StarPet stumbled upon a bug that was present for more than 20 years and was discovered and fixed by me just hours before.

Seemingly this issue is even more interesting.

I was unaware that any current distro makes txt2pho available via their regular installer. I have no idea what sources they use for this process. Are they relying on versions of txt2pho that date back to the days before the project was opensourced? Or do they just distribute the runtime executables made available by the website at the Uni Bonn? Or the first opensource version provided here?

In any case this would mean that they distribute a program that was last touched by a developer around the turn of the century - which is a situation I would like to improve...

[richardweinberger]

@richardweinberger: Thanks for reporting that this bug still exists in the wild - and for the subsequent debate.

Initially I was surprised by the sheer unlikeliness of this issue: @StarPet stumbled upon a bug that was present for more than 20 years and was discovered and fixed by me just hours before.

Recent compilers optimize aggressively and uncover often such issues.

Seemingly this issue is even more interesting.

I was unaware that any current distro makes txt2pho available via their regular installer. I have no idea what sources they use for this process. Are they relying on versions of txt2pho that date back to the days before the project was opensourced? Or do they just distribute the runtime executables made available by the website at the Uni Bonn? Or the first opensource version provided here?

In any case this would mean that they distribute a program that was last touched by a developer around the turn of the century - which is a situation I would like to improve...

I'm using the "mbrola" package shipped by OpenSUSE Packman. It worked for years but broke after I switched to a recent system. You can find their package sources here: https://pmbs.links2linux.de/package/show/Extra/mbrola

Rebuilding their package locally with commit https://github.com/GHPS/txt2pho/commit/2d1282c31ff3c76d0445dabd343e7a831368bddf included fixed the segfault.

I have reported this and another issue already to packman: https://lists.links2linux.de/pipermail/packman/2023-December/017692.html

Thanks a lot for looking into this!

[GHPS]

The more I look at this problem, the less I understand it...

For this distro they downloaded the first (and only) release versions for mbrola (released 2019) and txt2pho (released 2018) from the respective Github pages and packaged them. Both download links mention clearly that this is the initial open source state of the project.

In 2021 @lgbaldoni reported a problem with the build in gcc 11 (see issue #2). With his help a patch was developed as part of the general GCC 11 update.

At the same time he is the maintainer of the mbrola/txt2pho package but decided to pick only one line of the patch to get the old txt2pho running again. And therefore rejected any of the numerous other patches available in this repo and in mbrola.

And he added a new default settings file which he presumed was missing in the repo but was included in 2019. Unfortunately the new version had a problem with incorrect path separators.

In the end neither mbrola nor txt2pho have seen any significant updates in the distro - because the package maintainer(s) have chosen to take this path.

[lgbaldoni]

@GHPS you should know that the distro package has no current maintainer and, as caretaker, I did the bare minimum to get it building again.

Would you recommend using snapshot versions of both instead?

[GHPS]

@lgbaldoni Thanks for your reply - and making txt2pho/mbrola available to the SUSE community...

Would you recommend using snapshot versions of both instead?

In my opinion the answer is a clear yes.

For txt2pho the last years of development have come with improvements in code quality, a number of bugs (some of them serious) fixed and numerous wrong pronunciations corrected.

For mbrola the development towards version 3.4 has made some progress and a number of bugs were fixed.