Description of problem: > echo test | festival --tts zsh: done echo test | zsh: segmentation fault (core dumped) festival --tts But the same is true for a manual (SayText "test") invocation Version-Release number of selected component (if applicable): festival-1.96-32.fc24.x86_64 How reproducible: echo test | festival --tts Actual results: (gdb) bt #0 EST_Item::EST_Item (this=0x628630, rel=0x629ff0, li=0x0) at EST_Item.cc:167 #1 0x00007ffff743018d in EST_Relation::append (this=0x629ff0, si=0x0) at EST_Relation.cc:98 #2 0x00007ffff7b6609d in add_token (u=u@entry=0x6fe6a0, t=...) at text_aux.cc:47 #3 0x00007ffff7b654f3 in tts_chunk_stream (ts=..., app_tok=app_tok@entry=0x7ffff7b649a0 <tts_raw_token(EST_Item*)>, app_utt=app_utt@entry=0x7ffff7b649b0 <tts_raw_utt(LISP)>, eou_tree=0x7fffef4b9850, utt=0x7fffef609cf0, utt@entry=0x0) at text.cc:242 #4 0x00007ffff7b65a83 in tts_file_raw (filename=filename@entry=0x7fffef6072f0) at text.cc:169 #5 0x00007ffff7b65d07 in tts_file (filename=filename@entry=0x7fffef6072f0, mode=0x7fffef4c8dd0) at text.cc:106 #6 0x00007ffff7843b5a in leval (x=<optimized out>, env=<optimized out>, env@entry=0x0) at slib.cc:1390 #7 0x00007ffff7b29bac in festival_eval_command (command=...) at festival.cc:182 #8 0x00007ffff7b2a3c2 in festival_say_file (fname=...) at festival.cc:235 #9 0x000000000040286f in ?? () #10 0x0000000000401809 in main () Additional Info: This worked in F23 and has been broken since my update to F24. Given that festival didn't change I suspect it's in the underlying libraries somewhere.
I confirm this bug on Fedora 24 32-bit with festival-1.96-32.fc24.i686
I tried out a scratch build to see if rebuilding helped, but it didn't. My guess would be gcc changes. Really we should update to a more current version, but I don't see having time to do that any time soon. Any help would be appreciated.
*** Bug 1349198 has been marked as a duplicate of this bug. ***
I tried the latest source and couldn't even complete the speech-tools tests. It's frustrating that it compiles fine, then segfaults. I even tried a couple of things I thought made sense, but they didn't have any effect. Clearly, GCC 6.1.1 has no idea how to compile this code, anymore.
I too noticed this issue last night (festival segfaulting) and I'm hearing from others that there is a growing number of packages that segfault by default in Fedora 24 build. Of course these are packages that aren't present in the default package sets of Workstation or Server... and things that don't get a lot of testing during the development phase. Wonder if there is any way to improve things? I started using Fedora 24 pre-alpha and followed it along until release and have been using it on all my systems within a day or two of release... but the vast majority of programs people were telling me about were things I don't normally use. Yeah, this is not the right place to have this discussion but...
I have the same issue with festival-1.96-32.fc24.x86_64.
I've had this problem since Fedora24. Currently using Linux gandalf 4.7.7-200.fc24.x86_64 #1 SMP Sat Oct 8 00:21:59 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux Is Festival ever going to be working again? I prefer it to espeak.
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.
According to bug 1393019, changing the C++ standard setting for the build to GNU++98 and setting -fno-delete-null-pointer-checks is a successful workaround to get the compiled code to work. Apparently the code has some cases where methods are being called on null object pointers and changes in gcc optimization now result in the generated code crashing.
I too use festival and recently upgraded to F24 and after a while noticed my computer has stopped talking to me (it reads me reminders once in a while). I wouldn't mind maintaining it for Fedora if that's a possibility. I am not in the "Fedora system" but have been bz'ing here for 10 years, and try to help out where I can. I've gotten proficient at patching, rpmbuilding, bisecting, git'ing, etc. How could I get involved with this?
Trevor, that's awesome. I think that at the state we're in, the best thing to do would be to look at the current upstream packages and create a whole new from-scratch package, ignoring the very crufty current one. In fact, rather than one big crazy megapackage with all the sources, separate packages for the separate upstream sources. I'd recommend then providing this as a Copr https://copr.fedorainfracloud.org/ and then we can work on integrating it in and replacing the current packaging. If you've got the time and energy to work on this, I'd also suggest filing a new bug to track progress.
Hi, I probably should have posted here first. I exchanged emails with Alan Black, at the University of Edinburgh (festival.ac.uk). I told him of the situation, and he confirmed the problems with Festival and GCC6. They are working on revamping some of the code, and expect to have a new version perhaps "sometime during this semester". I have used Festival on my SPOCS SCADA project (//sourceforge.net/projects/spocs/) for years, and would like to continue using it, because it is easy to use, and produces very good quality speech.
Hey Trevor, Gary, anyone -- someone pinged me about this. Any interest in trying again to get this going?
Actually, let's move the discussion to #1457878
bug 1457878