mamedev
C++ error when auditing - flatpak
We get a C++ error when auditing on the flatpak version of mame on a Raspberry Pi 5. It gets to about 20,000 games, then crashes and says in terminal:
/usr/include/c++/14.2.0/array:208: constexpr std::array<_Tp, _Nm>::value_type& std::array<_Tp, _Nm>::operator [with _Tp = devcb_read
I've no clue what this means. Does anyone know how to fix this?
What do you mean by "audit"? What is the command-line/steps you are running? I also assume you are using MAME 0.274.
That looks like the libstdc++ assertions and indicates an actual bug (out of bound access of an array) in the code. Unfortunately without a full stacktrace that is a rather useless message.
It is strange that these are being triggered because they need to be explicitly enabled. Starting with GCC 15 they are enabled by default but only in an unoptimized build and I would expect a flatpak build to be optimized.
Yeah, we need to know:
- What you mean by “audit”
- Exact command line
- Full stack trace
- Which system/device it’s working with at the point it crashes
But if it’s a simple issue and not a nasty case of memory corruption or uninitialised values, it should be possible to reproduce it on a faster machine by building with these assertions enabled so you don’t need to work with a relatively slow ARM-based system.
I'm clicking the audit button in the gui. To get to the gui, I click MAME in the apps menu or run flatpak run org.mamedev.MAME
From: Vas Crabb @.> Sent: Monday, February 10, 2025 5:35:55 PM To: mamedev/mame @.> Cc: PrivateMe @.>; Author @.> Subject: Re: [mamedev/mame] C++ error when auditing - flatpak (Issue #13352)
Yeah, we need to know:
- What you mean by “audit”
- Exact command line
- Full stack trace
- Which system/device it’s working with at the point it crashes
But if it’s a simple issue and not a nasty case of memory corruption or uninitialised values, it should be possible to reproduce it on a faster machine by building with these assertions enabled so you don’t need to work with a relatively slow ARM-based system.
— Reply to this email directly, view it on GitHubhttps://github.com/mamedev/mame/issues/13352#issuecomment-2648770532, or unsubscribehttps://github.com/notifications/unsubscribe-auth/APTWCJKEPLZAHIDEGRWT6XT2PDPPXAVCNFSM6AAAAABW23IUWSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNBYG43TANJTGI. You are receiving this because you authored the thread.Message ID: @.***>
I'm using the device in school and don't have constant access to it, but if you tell me how to copy the stacktrace I can send it.
From: Owen Steele @.> Sent: Monday, February 10, 2025 8:00:30 PM To: mamedev/mame @.>; mamedev/mame @.> Cc: Author @.> Subject: Re: [mamedev/mame] C++ error when auditing - flatpak (Issue #13352)
I'm clicking the audit button in the gui. To get to the gui, I click MAME in the apps menu or run flatpak run org.mamedev.MAME
From: Vas Crabb @.> Sent: Monday, February 10, 2025 5:35:55 PM To: mamedev/mame @.> Cc: PrivateMe @.>; Author @.> Subject: Re: [mamedev/mame] C++ error when auditing - flatpak (Issue #13352)
Yeah, we need to know:
- What you mean by “audit”
- Exact command line
- Full stack trace
- Which system/device it’s working with at the point it crashes
But if it’s a simple issue and not a nasty case of memory corruption or uninitialised values, it should be possible to reproduce it on a faster machine by building with these assertions enabled so you don’t need to work with a relatively slow ARM-based system.
— Reply to this email directly, view it on GitHubhttps://github.com/mamedev/mame/issues/13352#issuecomment-2648770532, or unsubscribehttps://github.com/notifications/unsubscribe-auth/APTWCJKEPLZAHIDEGRWT6XT2PDPPXAVCNFSM6AAAAABW23IUWSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNBYG43TANJTGI. You are receiving this because you authored the thread.Message ID: @.***>
I can confirm the problem in MAME 0.275 Flatpak on Zorin OS and Linux Mint. It can be reproduced just by clicking "Audit Media" in the GUI.
Here's the error I get:
/usr/include/c++/14.2.0/array:208: constexpr std::array<_Tp, _Nm>::value_type& std::array<_Tp, _Nm>::operator: Assertion '__n < this->size()' failed.
I can confirm the problem in MAME 0.275 Flatpak on Zorin OS and Linux Mint. It can be reproduced just by clicking "Audit Media" in the GUI.
Here's the error I get:
/usr/include/c++/14.2.0/array:208: constexpr std::array<_Tp, _Nm>::value_type& std::array<_Tp, _Nm>::operator: Assertion '__n < this->size()' failed.
Once again, please obtain a full stack trace or at least work out what system/device it’s checking when it happens.
Hi, sorry for the lack of information but I'm not a developer. I'm just a user trying to help by reporting a problem. If it can be useful, I can confirm that the problem occurs on different hardware (Zorin OS) and also on a Linux Mint VM installed from scratch for testing reasons. I also add that even doing an Audit without any Rom present, the crash still occurs.
I attach a log in the hope that it can be useful in troubleshooting
We’d still be guessing as to what it’s trying to instantiate when it gets the error. It’s multi-threaded so it won’t be working strictly in alphabetical order. It’s probably something with a short name beginning with m or n. There appear to be about a dozen uses of devcb_read8::array<8> in MAME:
src/mame/namco/namco65.h: devcb_read8::array<8> m_port_analog_in_cb;
src/mame/namco/namco68.h: devcb_read8::array<8> m_port_analog_in_cb;
src/mame/sega/315_5296.h: devcb_read8::array<8> m_in_port_cb;
src/mame/sega/315_5649.h: devcb_read8::array<8> m_an_port_cb;
src/mame/sega/model1io.h: devcb_read8::array<8> m_an_cb;
src/mame/sega/model1io2.h: devcb_read8::array<8> m_an_cb;
src/mame/sony/znmcu.h: devcb_read8::array<8> m_analog_cb;
src/mame/vsystem/vs9209.h: devcb_read8::array<8> m_input_cb;
src/devices/machine/adc0808.h: devcb_read8::array<8> m_in_cb;
src/devices/machine/psion_asic2.h: devcb_read8::array<8> m_data_r;
src/devices/machine/psion_asic9.h: devcb_read8::array<8> m_data_r;
src/devices/sound/pokey.h: devcb_read8::array<8> m_pot_r_cb;
Trying to check all the uses for possible out-of-bounds accesses would be time-consuming to say the least. Several of those are devices, so it would be necessary to check everything that uses them as well.
At a glance:
- namco/namco65 looks safe, it always uses constant indices
- namco/namco68 appears to not use m_port_analog_in_cb at all
- sega/315_5296 looks safe
- sega/315_5649, sega/model1io and sega/model1io2 allow an index to be supplied by the caller for configuration, but all the uses look OK
- sony/znmcu allows an index to be supplied by the caller for configuration, but all the uses look OK
- vsystem/vs9209 looks safe
The others I really don’t have time to hunt for. If all of them look safe, then it’s either a memory corruption issue or a problem with the Flatpak that doesn’t affect regular builds.
Hi, thanks for the thorough analysis... I'm also pretty sure it's a problem with Flatpak's build. Is there anything I can do to help fix this bug or am I asking in the wrong place? Thanks in advance...
Well, there’s a chance it isn’t just a Flatpak issue.
Can you run the Flatpak version of MAME under GDB, and when it crashes, use the where command on the crashed thread to get a call stack? The info threads command lists threads, and you can use the thread command to switch threads.
Does your Linux distro produce crash dumps? If so, can you load the crash dump in GDB and get a call stack?
Ehm... It's not my bread and butter but tomorrow I will try to do what you're asking me.
Best regards!
Hi, I've tried to do my best with my limited knowledge and here are the results. Honestly I don't know if it can be useful but that's it.
I've also tried to extract the OS Crash Dump but it's a 474 MB file and I don't think it can be uploaded.
Thanks in advance and best regards!
OK, you’re making progress, but it seems to be catching it too late.
Can you load MAME in gdb again, but before running it, set a breakpoint on the abort function, i.e. type a b abort command before you type the run command. See if it hits the breakpoint on the assertion failure and you can get a useful backtrace.
I think this is an issue specific to the flatpak version. Using the version from the raspbian repository works fine, on the same hardware.
Same issue on MAME 0.276 from Flathub on Debian 12. The command is mame -verifyroms.
Tried to get a backtrace but it's useless because there are no debug symbols for the MAME flatpak package.
It happens with any machine in src/mame/apple/macpwrbk030.cpp (macpb140, macpb150, macpb160, macpb170, etc.) and doing anything like -listroms, -listcrc, -verifyroms.
__pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
44 return INTERNAL_SYSCALL_ERROR_P (ret) ? INTERNAL_SYSCALL_ERRNO (ret) : 0;
(gdb) bt
#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
#1 0x00007ffff5a9ae23 in __pthread_kill_internal (threadid=<optimized out>, signo=6) at pthread_kill.c:78
#2 0x00007ffff5a4208e in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#3 0x00007ffff5a29882 in __GI_abort () at abort.c:79
#4 0x00007ffff5ce8c1d in std::__glibcxx_assert_fail (file=<optimized out>, line=<optimized out>, function=<optimized out>, condition=<optimized out>)
at ../../../../../libstdc++-v3/src/c++11/assert_fail.cc:41
#5 0x00005555558648fa in std::array<devcb_read<unsigned char, (unsigned char)255>, 8ul>::operator[] (this=0x55555ba57488, __n=8)
at /usr/include/c++/14.2.0/array:208
#6 0x0000555555861938 in m50753_device::ad_in<8ul> (this=0x55555ba53520) at ../../../../../src/devices/cpu/m6502/m5074x.h:125
#7 0x0000555555854647 in (anonymous namespace)::macpb030_state::macpb140 (this=0x55555ba4e6b0, config=...) at ../../../../../src/mame/apple/macpwrbk030.cpp:1251
#8 0x00005555558619ae in driver_macpb140::{lambda(machine_config&, device_t&)#1}::operator()(machine_config&, device_t&) const (__closure=0x0, config=...,
owner=...) at ../../../../../src/mame/apple/macpwrbk030.cpp:1459
#9 0x00005555558619d9 in driver_macpb140::{lambda(machine_config&, device_t&)#1}::_FUN(machine_config&, device_t&) ()
at ../../../../../src/mame/apple/macpwrbk030.cpp:1459
#10 0x0000555555fe89af in driver_device::device_add_mconfig (this=0x55555ba4e6b0, config=...) at ../../../../../src/emu/driver.cpp:180
#11 0x0000555555f7e8fc in device_t::add_machine_configuration (this=0x55555ba4e6b0, config=...) at ../../../../../src/emu/device.cpp:226
#12 0x000055555795ec07 in machine_config::add_device (this=0x7fffffffc450, device=..., owner=0x0) at ../../../../../src/emu/mconfig.cpp:324
#13 0x000055555795f6ba in machine_config::device_add<emu::detail::device_type_impl_base const&, int> (this=0x7fffffffc450, tag=0x555559b8ec78 "root", type=...)
at ../../../../../src/emu/mconfig.h:196
#14 0x000055555795d7a8 in machine_config::machine_config (this=0x7fffffffc450, gamedrv=..., options=...) at ../../../../../src/emu/mconfig.cpp:51
#15 0x000055555845a1db in mame_options::parse_standard_inis (options=..., error_stream=..., driver=0x0) at ../../../../../src/frontend/mame/mameopts.cpp:61
#16 0x000055555845ab80 in mame_options::populate_hashpath_from_args_and_inis (options=..., args=std::vector of length 3, capacity 3 = {...})
at ../../../../../src/frontend/mame/mameopts.cpp:187
#17 0x000055555857f213 in cli_frontend::start_execution (this=0x7fffffffcc90, manager=0x55555ba32df0, args=std::vector of length 3, capacity 3 = {...})
at ../../../../../src/frontend/mame/clifront.cpp:222
#18 0x000055555857f826 in cli_frontend::execute (this=0x7fffffffcc90, args=std::vector of length 3, capacity 3 = {...})
at ../../../../../src/frontend/mame/clifront.cpp:293
#19 0x0000555558447720 in emulator_info::start_frontend (options=..., osd=..., args=std::vector of length 3, capacity 3 = {...})
at ../../../../../src/frontend/mame/mame.cpp:453
#20 0x0000555557c65a24 in main (argc=3, argv=0x7fffffffd158) at ../../../../../src/osd/sdl/sdlmain.cpp:100
It boils down to https://github.com/mamedev/mame/blob/master/src/mame/apple/macpwrbk030.cpp#L1267
which hits https://github.com/mamedev/mame/blob/master/src/devices/cpu/m6502/m5074x.h#L125
m_ad_in is defined in the same m5074x.h file, it's size is 8. The macpwrbk030.cpp shouldn't be calling ad_in<8>, the 8 is over the length of the array.
Should be 7 based on the comments in macpwrbk030.cpp. I submitted https://github.com/mamedev/mame/pull/13960
