Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1970764
| Summary: | [abrt] mame: std::__replacement_assert(): mame killed by SIGABRT | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Aleš Zima <ales.zima> | ||||||||||||||||||||
| Component: | mame | Assignee: | Julian Sikorski <belegdol> | ||||||||||||||||||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||||||||||||
| Severity: | unspecified | Docs Contact: | |||||||||||||||||||||
| Priority: | unspecified | ||||||||||||||||||||||
| Version: | 34 | CC: | belegdol | ||||||||||||||||||||
| Target Milestone: | --- | ||||||||||||||||||||||
| Target Release: | --- | ||||||||||||||||||||||
| Hardware: | x86_64 | ||||||||||||||||||||||
| OS: | Unspecified | ||||||||||||||||||||||
| URL: | https://retrace.fedoraproject.org/faf/reports/bthash/58e069cf972edff0867ff073741db58fa6d02357 | ||||||||||||||||||||||
| Whiteboard: | abrt_hash:50e13d91d9e540935527439340fea17c29a2d2fd;VARIANT_ID=workstation; | ||||||||||||||||||||||
| Fixed In Version: | mame-0.232-2.fc33 | Doc Type: | If docs needed, set a value | ||||||||||||||||||||
| Doc Text: | Story Points: | --- | |||||||||||||||||||||
| Clone Of: | Environment: | ||||||||||||||||||||||
| Last Closed: | 2021-06-23 01:13:37 UTC | Type: | --- | ||||||||||||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||||||||||||
| Documentation: | --- | CRM: | |||||||||||||||||||||
| Verified Versions: | Category: | --- | |||||||||||||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||||||||||
| Embargoed: | |||||||||||||||||||||||
| Attachments: |
|
||||||||||||||||||||||
|
Description
Aleš Zima
2021-06-11 07:30:32 UTC
Created attachment 1790113 [details]
File: backtrace
Created attachment 1790114 [details]
File: core_backtrace
Created attachment 1790115 [details]
File: cpuinfo
Created attachment 1790116 [details]
File: environ
Created attachment 1790117 [details]
File: limits
Created attachment 1790118 [details]
File: maps
Created attachment 1790119 [details]
File: mountinfo
Created attachment 1790120 [details]
File: open_fds
Created attachment 1790121 [details]
File: proc_pid_status
I unfortunately cannot reproduce this. mame-0.232 is working on two of my machines, an nvidia desktop and an amd laptop. Could you elaborate a bit more how you are making the assertion happen? Are you starting mame without a rom name and then picking one from the list? Or starting the machine directly (e.g. mame pacman)? There used to be an assertion when trying to display mameinfo.dat which is going to be fixed in 0.233. @Julian I have two desktops - AMD R7 with Radeon graphics and AMD R7 with nVidia graphics. Both running Fedora 34. And both have exactly same issue with mame (mame-0.232-1.fc34.x86_64). I use mame for running emulations of old dedicated chess computers. For example Saitek RISC2500: [ales@workstation ~]$ mame risc2500 /usr/include/c++/11/string_view:234: constexpr const value_type& std::basic_string_view<_CharT, _Traits>::operator[](std::basic_string_view<_CharT, _Traits>::size_type) const [with _CharT = char; _Traits = std::char_traits<char>; std::basic_string_view<_CharT, _Traits>::const_reference = const char&; std::basic_string_view<_CharT, _Traits>::size_type = long unsigned int]: Assertion '__pos < this->_M_len' failed. Aborted (core dumped) [ales@workstation ~]$ When compile and run mame from GitHub (MAME v0.232 (mame0232-168-g76c34a79b90)) everything is fine. @Julian Now i've tested on 3rd computer - laptop with intel Core i7 and Fedora 34. Exactly same result!!! It's hard to believe, that this can't be reproduced. I can reproduce it with a2500, thanks. Fedora mame package uses the standard Fedora compiler flags which includes -Wp,-D_GLIBCXX_ASSERTIONS. I have already found two cases in which this causes assertions to trigger. Was it working with 0.231? If so, one of us needs to bisect and report a bug upstream. The assertions go back as far as 0.228-2.fc34. Looks like bisecting is not going to be that trivial. I have managed to find a working revision. I still have some steps to bisect but it appears that the assertion might be related to switch from .png to .svg chess pieces. I would like to help, but I'm just a slightly advanced user. FEDORA-2021-8793f80b80 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-8793f80b80 FEDORA-2021-caa880a8ae has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-caa880a8ae FEDORA-2021-caa880a8ae has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-caa880a8ae` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-caa880a8ae See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2021-8793f80b80 has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-8793f80b80` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-8793f80b80 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2021-caa880a8ae has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report. FEDORA-2021-8793f80b80 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report. |