Description of problem: Festival crashes on a simplest command Version-Release number of selected component (if applicable): festival-1.96-32.fc24.x86_64 How reproducible: every time Steps to Reproduce: 1. run commandline 'festival' 2. type simple command (SayText "Hello") Actual results: instant SEGV crash, no output Expected results: correct operation, sound output, no crash
Stack frame at crash: #0 EST_Item::EST_Item (this=0x7180a0, rel=0x717f40, li=0x0) at EST_Item.cc:167 set_contents(li->contents()); #1 0x00007ffff743018d in EST_Relation::append (this=0x717f40, si=0x0) at EST_Relation.cc:98 #2 0x00007ffff7b6609d in add_token (u=u@entry=0x6fe8b0, t=...) at text_aux.cc:47 #3 0x00007ffff7b64e63 in FT_Text_Utt (utt=0x7fffef6065f0) at text.cc:92 #4 0x00007ffff7843ae7 in leval (x=<optimized out>, env=<optimized out>, ... The 'li' variable is NULL; it's coming via the 'si' in frame #2, which in turn comes from text_aux.cc:47: EST_Item *add_token(EST_Utterance *u,EST_Token &t) │ │45 { │ │46 // Add a token stream item to the end of Token relation │ >│47 EST_Item *item = u->relation("Token")->append(); It looks like append() expects the 'si' argument, but is called without it? Change in API?
I just upgraded to Fedora 24 today and I'm seeing exactly the same thing.
Thanks for doing that analysis. I'll see if I can use that to get it working again in f24. I plan to retire Festival in f25. It needs a significant upgrade that I don't have time to do. A new review is probably justified so retirement won't really add a lot of work if someone is interested in taking over.
I'm interesting to keep Festival in Fedora. I compiled Festival from sources. It works under Fedora24.
Why worry about a significant upgrade if keeping it alive will suffice for most users. We are interested in keeping it here as we use it for speech synthesis on our robots. I had a brief look. Even though the de-referencing of the nullptr can be solved easily, it still crashes later when iterating through the utterance. This I couldn't find quickly. I have also tried building with -std=c++98 or gnu++98 without luck. The code seems to assume that it is ok to make checks inside methods of the form "if (this == 0) ...", usually returned a specific value. Strictly speaking, this is not allowed in C++. It seems this was tolerated before GCC6, but is not any longer. Fixing this probably means to please checks sooner. There is also code plain wrong even if that check would work, e.g.: "return n->first()->up();", where first() may already return 0. Festival has dozens of committers (https://admin.fedoraproject.org/pkgdb/package/rpms/festival/). Someone ought to have the time to fix this. I have attached a small patch which makes the problem obvious but fixes only the basic initial problems.
Created attachment 1204811 [details] Preliminary patch exposing some problems
The problem with the old version is not getting fixes for bugs, especially ones with security implications. If someone is interested in getting back into f25 after it is retired, they can become a packager for it. There is still time to get the current version packaged before f25 is released. I should be able to try out your patches soon to try to get it to at least work again in f24. I don't think we can expect much help with the other committers. Matthew was hoping to be able to put in significant effort at one time, but then got roped into being the Fedora Project Leader which is keeping him pretty busy.
The Festival package in Fedora needs a lot of work to update to a newer release, fix a lot of bugs, and generally clean up the packaging. And, despite best intentions, we just haven't had the developer interest in doing so. The current plan is to retire Festival from Fedora. See thread at https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/UOL4ETKKOFGTFZZ36V726OF7UTHYMEYP/ for discussion. Despite being large, slow, and fragile, Festival is interesting software and as far as I know can produce the best quality results of any open-source TTS system. It would be nice if there is interest in continuing it, but that should probably be done from a clean slate in any case. In the meantime, I think it's most honest to close the currently-open bugs as "WONTFIX". Thanks everyone for your reports and effort in making Fedora better.