mamedev / mame

MAME
https://www.mamedev.org/
Other
8.42k stars 2.04k forks source link

assertion failure when attempting to start risc2500 #8186

Closed belegdol closed 3 years ago

belegdol commented 3 years ago

Hello, Fedora package throws an assertion failure when attempting to start risc2500:

$ 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.

This is due to the package being compiled with OPT_FLAGS=-Wp,-D_GLIBCXX_ASSERTIONS. I have managed to bisect the issue down to aa29519528cb3dbdbfac56819bea670ed8c56c5d.

belegdol commented 3 years ago

This is the backtrace with the latest git:

Starting program: /usr/bin/mame risc2500
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
49    return ret;
Missing separate debuginfos, use: dnf debuginfo-install SDL2-2.0.14-3.fc34.x86_64 SDL2_ttf-2.0.15-7.fc34.x86_64 alsa-lib-1.2.5-2.fc34.x86_64 bzip2-libs-1.0.8-6.fc34.x86_64 dbus-libs-1.12.20-3.fc34.x86_64 expat-2.2.10-2.fc34.x86_64 flac-libs-1.3.3-7.fc34.x86_64 fontconfig-2.13.93-6.fc34.x86_64 freetype-2.10.4-3.fc34.x86_64 glib2-2.68.2-1.fc34.x86_64 graphite2-1.3.14-7.fc34.x86_64 gsm-1.0.19-5.fc34.x86_64 harfbuzz-2.7.4-3.fc34.x86_64 jack-audio-connection-kit-1.9.17-1.fc34.x86_64 libICE-1.0.10-6.fc34.x86_64 libX11-1.7.0-3.fc34.x86_64 libX11-xcb-1.7.0-3.fc34.x86_64 libXScrnSaver-1.2.3-8.fc34.x86_64 libXau-1.0.9-6.fc34.x86_64 libXext-1.3.4-6.fc34.x86_64 libXfixes-5.0.3-14.fc34.x86_64 libXi-1.7.10-6.fc34.x86_64 libasyncns-0.8-20.fc34.x86_64 libbrotli-1.0.9-4.fc34.x86_64 libcap-2.48-2.fc34.x86_64 libdb-5.3.28-46.fc34.x86_64 libgcc-11.1.1-3.fc34.x86_64 libgcrypt-1.9.3-2.fc34.x86_64 libglvnd-glx-1.3.3-1.fc34.x86_64 libgpg-error-1.42-1.fc34.x86_64 libicu-67.1-6.fc34.x86_64 libjpeg-turbo-2.0.90-2.fc34.x86_64 libogg-1.3.4-4.fc34.x86_64 libpng-1.6.37-10.fc34.x86_64 libselinux-3.2-1.fc34.x86_64 libsndfile-1.0.31-3.fc34.x86_64 libstdc++-11.1.1-3.fc34.x86_64 libuuid-2.36.2-1.fc34.x86_64 libvorbis-1.3.7-3.fc34.x86_64 libxcb-1.13.1-7.fc34.x86_64 libxml2-2.9.12-4.fc34.x86_64 libzstd-1.5.0-1.fc34.x86_64 lz4-libs-1.9.3-2.fc34.x86_64 opus-1.3.1-8.fc34.x86_64 pcre-8.44-3.fc34.1.x86_64 pcre2-10.36-4.fc34.x86_64 pcre2-utf16-10.36-4.fc34.x86_64 portaudio-19-34.fc34.x86_64 portmidi-217-39.fc34.x86_64 pugixml-1.11.4-2.fc34.x86_64 qt5-qtbase-5.15.2-15.fc34.x86_64 qt5-qtbase-gui-5.15.2-15.fc34.x86_64 sqlite-libs-3.34.1-2.fc34.x86_64 systemd-libs-248.3-1.fc34.x86_64 utf8proc-2.6.1-2.fc34.x86_64 zlib-1.2.11-26.fc34.x86_64
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
        set = {__val = {0, 140737488312160, 0, 93825325206656, 140737488311376, 93825326909824, 93825326908896, 93825198156062, 
            4405601298448121856, 4575657222473777152, 1065353216, 0, 140733193388032, 140737321828108, 140737488309352, 0}}
        pid = <optimized out>
        tid = <optimized out>
        ret = <optimized out>
#1  0x00007ffff60cb8a4 in __GI_abort () at abort.c:79
        save_stage = 1
        act = {__sigaction_handler = {sa_handler = 0x9, sa_sigaction = 0x9}, sa_mask = {__val = {93825238493160, 234, 
              93825246323160, 93825246323137, 0, 140737488311408, 3, 8, 93825326909192, 11, 140737325929368, 1, 140737488309648, 
              140737488311400, 93825324173760, 14}}, sa_flags = -162484601, sa_restorer = 0x1}
        sigs = {__val = {32, 140737321834440, 16, 5161462845359089408, 0, 5161462845359089408, 11, 13, 140737488311400, 
            93825326909198, 14, 140737321622399, 206158430248, 140737488309696, 140737488309504, 5161462845359089408}}
#2  0x0000555559c974d8 in std::__replacement_assert () at /usr/include/c++/11/x86_64-redhat-linux/bits/c++config.h:2654
No locals.
#3  0x00005555619d157a in std::basic_string_view<char, std::char_traits<char> >::operator[] ()
    at /usr/include/c++/11/string_view:234
No locals.
#4  std::basic_string_view<char, std::char_traits<char> >::operator[] () at /usr/include/c++/11/string_view:232
No locals.
#5  emu::render::detail::layout_environment::expand () at ../../../../../src/emu/rendlay.cpp:553
No locals.
#6  0x00005555619b7b34 in emu::render::detail::layout_environment::get_attribute_subtag[abi:cxx11](util::xml::data_node const&, char const*) () at ../../../../../src/emu/rendlay.cpp:779
No locals.
#7  layout_view::item::make_input_tag[abi:cxx11](emu::render::detail::view_environment&, util::xml::data_node const&) ()
    at ../../../../../src/emu/rendlay.cpp:4974
No locals.
#8  layout_view::item::item () at ../../../../../src/emu/rendlay.cpp:4527
No locals.
#9  0x00005555619b9c57 in __gnu_cxx::new_allocator<std::_List_node<layout_view::item> >::construct<layout_view::item, emu::render::detail::view_environment&, util::xml::data_node const&, std::unordered_map<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, layout_element, std::hash<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::equal_to<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, layout_element> > >&, int&, std::array<std::array<float, 3ul>, 3ul> const&, render_color const&> () at /usr/include/c++/11/ext/new_allocator.h:156
No locals.
#10 std::allocator_traits<std::allocator<std::_List_node<layout_view::item> > >::construct<layout_view::item, emu::render::detail::view_environment&, util::xml::data_node const&, std::unordered_map<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, layout_element, std::hash<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::equal_to<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, layout_element> > >&, int&, std::array<std::array<float, 3ul>, 3ul> const&, render_color const&> () at /usr/include/c++/11/bits/alloc_traits.h:512
No locals.
#11 std::__cxx11::list<layout_view::item, std::allocator<layout_view::item> >::_M_create_node<emu::render::detail::view_environment&, util::xml::data_node const&, std::unordered_map<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, layout_element, std::hash<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::equal_to<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, layout_element> > >&, int&, std::array<std::array<float, 3ul>, 3ul> const&, render_color const&> () at /usr/include/c++/11/bits/stl_list.h:637
No locals.
#12 std::__cxx11::list<layout_view::item, std::allocator<layout_view::item> >::_M_insert<emu::render::detail::view_environment&, util::xml::data_node const&, std::unordered_map<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, layout_element, std::hash<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::equal_to<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, layout_element> > >&, int&, std::array<std::array<float, 3ul>, 3ul> const&, render_color const&> () at /usr/include/c++/11/bits/stl_list.h:1911
No locals.
#13 std::__cxx11::list<layout_view::item, std::allocator<layout_view::item> >::emplace_back<emu::render::detail::view_environment&, util::xml::data_node const&, std::unordered_map<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, layout_element, std::hash<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::equal_to<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, layout_element> > >&, int&, std::array<std::array<float, 3ul>, 3ul> const&, render_color const&> () at /usr/include/c++/11/bits/stl_list.h:1227
No locals.
#14 layout_view::add_items () at ../../../../../src/emu/rendlay.cpp:4354
No locals.
#15 0x00005555619babd4 in layout_view::add_items () at ../../../../../src/emu/rendlay.cpp:4441
No locals.
#16 0x00005555619ba6fd in layout_view::add_items () at ../../../../../src/emu/rendlay.cpp:4420
No locals.
#17 0x00005555619bb261 in layout_view::layout_view () at ../../../../../src/emu/rendlay.cpp:3985
No locals.
#18 0x00005555619bc254 in __gnu_cxx::new_allocator<std::_List_node<layout_view> >::construct<layout_view, emu::render::detail::layout_environment&, util::xml::data_node const&, std::unordered_map<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, layout_element, std::hash<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::equal_to<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, layout_element> > >&, std::unordered_map<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, layout_group, std::hash<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::equal_to<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, layout_group> > >&> ()
    at /usr/include/c++/11/ext/new_allocator.h:156
No locals.
#19 std::allocator_traits<std::allocator<std::_List_node<layout_view> > >::construct<layout_view, emu::render::detail::layout_environment&, util::xml::data_node const&, std::unordered_map<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, layout_element, std::hash<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::equal_to<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, layout_element> > >&, std::unordered_map<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, layout_group, std::hash<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::equal_to<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, layout_group> > >&> () at /usr/include/c++/11/bits/alloc_traits.h:512
No locals.
#20 std::__cxx11::list<layout_view, std::allocator<layout_view> >::_M_create_node<emu::render::detail::layout_environment&, util::xml::data_node const&, std::unordered_map<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, layout_element, std::hash<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::equal_to<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, layout_element> > >&, std::unordered_map<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, layout_group, std::hash<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::equal_to<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, layout_group> > >&> () at /usr/include/c++/11/bits/stl_list.h:637
No locals.
#21 std::__cxx11::list<layout_view, std::allocator<layout_view> >::_M_insert<emu::render::detail::layout_environment&, util::xml::data_node const&, std::unordered_map<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, layout_element, std::hash<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::equal_to<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, layout_element> > >&, std::unordered_map<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, layout_group, std::hash<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::equal_to<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, layout_group> > >&> () at /usr/include/c++/11/bits/stl_list.h:1911
No locals.
#22 std::__cxx11::list<layout_view, std::allocator<layout_view> >::emplace_back<emu::render::detail::layout_environment&, util::xml::data_node const&, std::unordered_map<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, layout_element, std::hash<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::equal_to<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, layout_element> > >&, std::unordered_map<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, layout_group, std::hash<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::equal_to<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, layout_group> > >&> () at /usr/include/c++/11/bits/stl_list.h:1227
No locals.
#23 layout_file::layout_file () at ../../../../../src/emu/rendlay.cpp:5088
No locals.
#24 0x000055556199dc54 in __gnu_cxx::new_allocator<std::_List_node<layout_file> >::construct<layout_file, device_t&, util::xml::data_node const&, char const*&, char const*&> () at /usr/include/c++/11/ext/new_allocator.h:156
No locals.
#25 std::allocator_traits<std::allocator<std::_List_node<layout_file> > >::construct<layout_file, device_t&, util::xml::data_node const&, char const*&, char const*&> () at /usr/include/c++/11/bits/alloc_traits.h:512
No locals.
#26 std::__cxx11::list<layout_file, std::allocator<layout_file> >::_M_create_node<device_t&, util::xml::data_node const&, char const*&, char const*&> () at /usr/include/c++/11/bits/stl_list.h:637
No locals.
#27 std::__cxx11::list<layout_file, std::allocator<layout_file> >::_M_insert<device_t&, util::xml::data_node const&, char const*&, char const*&> () at /usr/include/c++/11/bits/stl_list.h:1911
No locals.
#28 std::__cxx11::list<layout_file, std::allocator<layout_file> >::emplace_back<device_t&, util::xml::data_node const&, char const*&, char const*&> () at /usr/include/c++/11/bits/stl_list.h:1227
No locals.
#29 render_target::load_layout_file () at ../../../../../src/emu/render.cpp:2201
No locals.
#30 0x000055556199ddf3 in render_target::load_layout_file () at ../../../../../src/emu/render.cpp:2136
No locals.
#31 0x00005555619a7ac5 in operator() () at ../../../../../src/emu/render.cpp:1698
No locals.
#32 apply_default_layouts<render_target::load_additional_layout_files(char const*, bool)::<lambda(device_t&, const internal_layout&)> > () at ../../../../../src/emu/mconfig.h:127
No locals.
#33 render_target::load_additional_layout_files () at ../../../../../src/emu/render.cpp:1696
No locals.
#34 0x00005555619aad34 in render_target::load_layout_files () at ../../../../../src/emu/render.cpp:1651
No locals.
#35 render_target::render_target<internal_layout const*&> () at ../../../../../src/emu/render.cpp:952
No locals.
#36 0x00005555619a99dc in render_target::render_target () at ../../../../../src/emu/render.cpp:884
No locals.
#37 render_manager::target_alloc () at ../../../../../src/emu/render.cpp:3113
No locals.
#38 0x000055555d8c02bb in osd_window::create_target () at ../../../../../src/osd/modules/osdwindow.cpp:110
No locals.
#39 0x000055555d8b34df in sdl_window_info::window_init () at ../../../../../src/osd/sdl/window.cpp:411
No locals.
#40 0x000055555d8ae87e in sdl_osd_interface::video_init () at ../../../../../src/osd/sdl/video.cpp:79
No locals.
#41 0x000055555d8b96a5 in osd_common_t::init_subsystems () at ../../../../../src/osd/modules/lib/osdobj_common.cpp:657
No locals.
#42 0x000055555d8ac297 in sdl_osd_interface::init () at ../../../../../src/osd/sdl/sdlmain.cpp:506
No locals.
#43 0x000055556198b8c0 in running_machine::start () at ../../../../../src/emu/machine.cpp:203
No locals.
#44 0x000055556198d6dc in running_machine::run () at ../../../../../src/emu/machine.cpp:333
No locals.
#45 0x000055555d993c21 in mame_machine_manager::execute () at ../../../../../src/frontend/mame/mame.cpp:269
No locals.
#46 0x000055555da306ad in cli_frontend::start_execution () at ../../../../../src/frontend/mame/clifront.cpp:269
No locals.
#47 0x000055555da308d2 in cli_frontend::execute () at ../../../../../src/frontend/mame/clifront.cpp:285
No locals.
#48 0x000055555d9913ba in emulator_info::start_frontend () at ../../../../../src/frontend/mame/mame.cpp:400
No locals.
#49 0x0000555559bba593 in main () at ../../../../../src/osd/sdl/sdlmain.cpp:219
No locals.
belegdol commented 3 years ago

ping @ajrhacker

ajrhacker commented 3 years ago

7b27b93875bb230579bcdd40a7c93a85f0761dba should fix this. Looks like it's yet another case of -D_GLIBCXX_ASSERTIONS disallowing the idiomatic C method of taking the address of one past the end.

cuavas commented 3 years ago

You know, we use things like string view and vector because they're cheap abstractions based on pointers. If you're building MAME for distribution with these bounds checks enabled it's hurting performance. So far none of the issues raised have been real problems. I'm starting to wonder if it wouldn't be better insist that you build with recommended options or call it something else. At any rate, you should debug these things yourself.

belegdol commented 3 years ago

7b27b93 fixes the problem indeed, thanks @ajrhacker. Regarding the use of distribution compiler flags: I am sorry for the trouble this is causing. The flags are unfortunately mandated by the packaging guidelines [1]: Compilers used to build packages must honor the applicable compiler flags set in the system rpm configuration. Honoring means that the contents of that variable is used as the basis of the flags actually used by the compiler during the package build. -D_GLIBCXX_ASSERTIONS was added during Fedora 28 release cycle [2]. According to the feature page, the assertions were meant to be lightweight. In any case, unless mame is rewritten in SAS, all I can do in terms of debugging is to provide a backtrace and a git bisect. I might try getting a guidelines exception, but if that fails, I might need to abandon the mame package.

[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/#_compiler_flags [2] https://fedoraproject.org/wiki/Changes/HardeningFlags28

cuavas commented 3 years ago

I take issue with this because MAME isn't secure software, and MAME is performance-sensitive.

I'd be horribly shocked if there aren't VM escape vulnerabilities in multiple CPU cores, allowing malicious guest software to run arbitrary code on the host, in the context of the user running MAME. These assertions do nothing to mitigate that, they don't do anything for the actual risky code.

Even if the assertions are supposed to be "light-weight" they still add a conditional branch to every index operation on a container class. Besides the decode overhead, each of these will consume a branch predictor slot (even if they're always predicted correctly), potentially evicting something useful. They also cause pipeline dependencies involving condition codes on most host architectures (potential exceptions being things like HyperStone and Thumb-EE that have special range-checking instructions for supporting Java, or MIPS and Alpha that eschew dedicated condition code registers).

So in purely technical terms, it adds overhead to relatively safe code while doing nothing to mitigate risks where the potential danger is.

On top of that, if you're going to be opening an issue and expecting us to debug it every time you encounter one of these, it's just going to cause friction. So far, none of them have been real problems. At best these assertions might catch stuff we can find by running under valgrind anyway, but so far they haven't even done that. As far as I'm concerned, so far they've been a pure downstream issue caused by options you use against our recommendations. That should be your responsibility to debug and work around.

We've had issues with the dubious "fortify source" feature already. Now we've got these container debugging assertions in release builds as well. When does it stop? And why should the effort to support a downstream configuration we recommend against be pushed onto us?

belegdol commented 3 years ago

I can completely understand your arguments. For reference, "fortify source" is part of Fedora optflags as well:

$ rpm --eval %optflags
-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection

As a packager without C++ knowledge I am stuck between distribution guidelines mandating the use of the system-wide compiler flags and upstream developers, annoying whom is the last thing I wish. I will look into getting a packaging guidelines exception granted for mame. Would it be OK if I quoted your comments in the request? If the exception is not granted, it might ultimately be better to drop mame from official Fedora repos if it is going to waste your time and drag the performance down for everyone in the long term.

cuavas commented 3 years ago

I know a significant number of users like the convenience of having a recent version of MAME available from their Linux distribution’s primary package repository, and it would be unfortunate to lose that. However, there are issues for us if the distribution requires the software to be built in a way we don’t recommend/support. In this case, it’s hard crashes on assertion failures that aren’t real memory issues, and performance degradation. If it’s going to be like this, it at least needs a disclaimer/notice that we can’t support it ourselves and issues should be raised with the distro packagers.

belegdol commented 3 years ago

I have requested a packaging guidelines exception in order to drop -Wp,-D_GLIBCXX_ASSERTIONS from the compiler flags. I will let you know the outcome.

npwoods commented 3 years ago

Isn't (according to the letter of the law) using operator[] on vector and string_view technically undefined behavior in C++? It feels like these problems should be identified and fixed for that reason alone.

That said, I also agree that Fedora's mandate of _GLIBCXX_ASSERTIONS is silly for projects like MAME.

cuavas commented 3 years ago

Isn't (according to the letter of the law) using operator[] on vector and string_view technically undefined behavior in C++?

It’s technically undefined, but in this case it’s completely harmless because of C’s guarantee that &*x is equivalent to x (i.e. you’ll just get the same pointer, even if it points to an invalid address, it won’t magically cause the computer to blow up), and the length is zero so it won’t attempt to dereference it. So far all the cases that have hit these assertions have been things like this.