Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

C++ error when auditing - flatpak #13352

Open
privatedev11 opened this issue Feb 10, 2025 · 11 comments
Open

C++ error when auditing - flatpak #13352

privatedev11 opened this issue Feb 10, 2025 · 11 comments

Comments

@privatedev11
Copy link

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; long unsigned int _Nm = 8; reference = devcb_read&; size_type = long unsigned int]: Assertion '__n < this->size()' failed.
/usr/include/c++/14.2.0/array:208: constexpr std::array<_Tp, _Nm>::value_type& std::array<_Tp, _Nm>::operator [with _Tp = devcb_read; long unsigned int _Nm = 8; reference = devcb_read&; size_type = long unsigned int]: Assertion '__n < this->size()' failed.

I've no clue what this means. Does anyone know how to fix this?
@firewave
Copy link
Contributor

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.

@cuavas
Copy link
Member

cuavas commented Feb 10, 2025

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.

@privatedev11
Copy link
Author

privatedev11 commented Feb 10, 2025 via email

@privatedev11
Copy link
Author

privatedev11 commented Feb 10, 2025 via email

@LukeSiren
Copy link

LukeSiren commented Feb 26, 2025 •
edited
Loading

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.

@cuavas
Copy link
Member

cuavas commented Feb 28, 2025

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.

@LukeSiren
Copy link

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

mame_audit_log.txt

@cuavas
Copy link
Member

cuavas commented Mar 1, 2025 •
edited
Loading

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.

@LukeSiren
Copy link

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

@cuavas
Copy link
Member

cuavas commented Mar 1, 2025

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?

@LukeSiren
Copy link

Ehm... It's not my bread and butter but tomorrow I will try to do what you're asking me.

Best regards!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@firewave @cuavas @privatedev11 @LukeSiren