Bug 1393019
| Summary: | Festival coredumps | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jaroslav Škarvada <jskarvad> | ||||
| Component: | festival | Assignee: | Bruno Wolff III <bruno> | ||||
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | rawhide | CC: | bruno, D8F55524, dellroygm, mattdm, rebus, tim | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2017-06-02 13:13:50 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
Hi, I guess it is duplicate of #1370990, #1336981. I have even tried to update the package to 2.4, but it didn't help. https://rebus.fedorapeople.org/SRPMS/festival-2.4-1.fc24.src.rpm The error is the same in 2.4 as well. Best regards Michal Ambroz Created attachment 1220980 [details] Workaround It seems the festival source code is ugly and not compatible with the C++14 standard. I only quickly overlooked it, but I was still able to identify at least one type of problem related to relaying on undefined behaviour regarding invocation of the member functions through a NULL pointer which led to the crash. However there are more problems with the code. The problems manifests with the GCC-6 which switched to the GNU++14 standard by default. The festival code should be fixed to comply with the standard and not rely on undefined behaviour. See [1] for details. The workaround patch switches to the GNU++98 standard and disables optimizations regarding null pointer checks for 'this'. This is not correct solution, but still better than the crash. [1] https://gcc.gnu.org/gcc-6/porting_to.html Hello, I had an exchange with Alan Black at the University of Edinburgh, (festival.ac.uk) the creators of Festival. I appraised him of the situation with GCC6. He confirmed the problem, and said they were working on it, but not to expect a new release before the end of their college semester. -Gary Sprang (In reply to Gary Sprang from comment #3) > Hello, > I had an exchange with Alan Black at the University of Edinburgh, > (festival.ac.uk) the creators of Festival. I appraised him of the > situation with GCC6. He confirmed the problem, and said they were working > on it, but not to expect a new release before the end of their college > semester. > -Gary Sprang Thanks for info, could you commit the workaround until new version of Festival is released? I think it's better to have it working and compiled with workarounds instead of having it "vanilla" and crashing. *** This bug has been marked as a duplicate of bug 1457878 *** This comment was flagged a spam, view the edit history to see the original text if required. |
Description of problem: Festival coredumps Version-Release number of selected component (if applicable): festival-1.96-32.fc24.x86_64 How reproducible: Always Steps to Reproduce: 1. echo hi | festival --tts 2. echo hi > test.txt 3. festival --tts test.txt Actual results: Program terminated with signal SIGSEGV, Segmentation fault. Expected results: No core dump. Additional info: #0 EST_Item::EST_Item (this=0x17b1a10, rel=0x18b57b0, li=0x0) at EST_Item.cc:167 #1 0x00007f37ee3eb18d in EST_Relation::append (this=0x18b57b0, si=0x0) at EST_Relation.cc:98 #2 0x00007f37eeb2109d in add_token (u=u@entry=0x189cf30, t=...) at text_aux.cc:47 #3 0x00007f37eeb204f3 in tts_chunk_stream (ts=..., app_tok=app_tok@entry=0x7f37eeb1f9a0 <tts_raw_token(EST_Item*)>, app_utt=app_utt@entry=0x7f37eeb1f9b0 <tts_raw_utt(LISP)>, eou_tree=0x7f37e6485d90, utt=0x7f37e66d9f70, utt@entry=0x0) at text.cc:242 #4 0x00007f37eeb20a83 in tts_file_raw (filename=filename@entry=0x7f37e66d7570) at text.cc:169 #5 0x00007f37eeb20d07 in tts_file (filename=filename@entry=0x7f37e66d7570, mode=0x7f37e6495310) at text.cc:106 #6 0x00007f37ee7feb5a in leval (x=<optimized out>, env=<optimized out>, env@entry=0x0) at slib.cc:1390 #7 0x00007f37eeae4bac in festival_eval_command (command=...) at festival.cc:182 #8 0x00007f37eeae53c2 in festival_say_file (fname=...) at festival.cc:235 #9 0x0000000000402570 in ?? () #10 0x0000000000401809 in main ()