Viewing Issue Advanced Details
ID Category [?] Severity [?] Reproducibility Date Submitted Last Update
07350 Crash/Freeze Critical (emulator) Always Jun 5, 2019, 12:37 Jun 19, 2019, 15:43
Tester MrGW View Status Public Platform MAME (Self-compiled)
Assigned To Resolution No change required OS Linux (32-bit)
Status [?] Closed Driver
Version 0.210 Fixed in Version Build 32-bit
Summary 07350: MAME 0.210 segfaults at startup
Description MAME 0.210 dies with a segmentation fault almost immediately after starting it. This is on a Raspbian system (RPi3).

I have been compiling MAME for the RPi3 the last couple of years. It wasn't until this latest version (MAME 0.210) that I saw a segmentation fault. If I pull the source for the previous release (0.209) no issues at all.

I did an 'objdump -p' to the compiled binary for 0.209 (working) and 0.210 (non-working) and found the following differences:

MAME 0.210 requires these libraries not found in previous versions:


I'm guessing this has something to do with the segfault.
Steps To Reproduce git pull latest MAME source.
Compile MAME using the standard 'makefile' using the 'make' comm

Launch MAME. The UI will just start to show and then it dies with a segmentation fault.
Additional Information Some debugger information:

pi@cocopi3:~/.mame $ gdb /opt/mame-0.210-gcc8-qemu/mame
GNU gdb (Raspbian 7.12-6)
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
Find the GDB manual and other documentation resources online at:
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /opt/mame-0.210-gcc8-qemu/mame...done.
(gdb) run
Starting program: /opt/mame-0.210-gcc8-qemu/mame
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/".
[New Thread 0x737b9440 (LWP 28906)]
[New Thread 0x72dff440 (LWP 28907)]
[New Thread 0x725fe440 (LWP 28908)]
[New Thread 0x71dfd440 (LWP 28909)]
[New Thread 0x715bb440 (LWP 28910)]
[New Thread 0x706f9440 (LWP 28911)]

Thread 1 "mame" received signal SIGSEGV, Segmentation fault.
0x75e0b104 in XPending () from /usr/lib/arm-linux-gnueabihf/
(gdb) backtrace
#0 0x75e0b104 in XPending () from /usr/lib/arm-linux-gnueabihf/
#1 0x00144c98 in x11_lightgun_module::before_poll(running_machine&) ()
#2 0x000e9270 in sdl_osd_interface::poll_inputs(running_machine&) ()
#3 0x000e0464 in sdl_osd_interface::update(bool) ()
#4 0x01249548 in video_manager::frame_update(bool) ()
#5 0x0019d64c in mame_machine_manager::create_ui(running_machine&) ()
#6 0x011cbe38 in running_machine::start() ()
#7 0x011cd0e4 in running_machine::run(bool) ()
#8 0x0019fda8 in mame_machine_manager::execute() ()
#9 0x00219010 in cli_frontend::start_execution(mame_machine_manager*, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&) ()
#10 0x00219304 in cli_frontend::execute(std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >&) ()
#11 0x0019e190 in emulator_info::start_frontend(emu_options&, osd_interface&, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >&) ()
#12 0x0005e4cc in main ()
Regression Version 0.210
Affected Sets / Systems
Attached Files
There are no relationship linked to this issue.
User avatar
Jun 5, 2019, 12:44
I do not know if we support this. Open for comments please.
User avatar
Jun 14, 2019, 15:39
Since I had experienced another issue with 0.210 (see bug report #7358) I figured I would pull the current source, compile and test again. Same issue for the RPi3 (ARM). 2 additional libraries are pulled in (, and MAME will segfault just as it starts to render the UI.

I realize ARM architecture may not be supported, but it has been working for over 2 years. Isn't there anyone else compiling MAME for the Raspberry Pi?
User avatar
Jun 14, 2019, 16:50
On team, I'm not sure. The project head hasn't been around much lately and I suspect he would have the most knowledge regarding alternative SDL (non-windows) builds.
I do know there is someone who would regular compile on PI, but it appears he may no longer do it due to time taken?

Are you compiling it on the device or doing a cross compile?
User avatar
Jun 14, 2019, 19:21
Hi Tafoid,

I started doing a cross compile over a year ago using qemu on my Linux workstation. It cut the compile down from 16+ hours to about 2 hours. Big difference. As I had mentioned, things have been working very well up until 0.210. I'm sure it has to do with those new libraries, but can't figure out why they were added (or even needed).

MAME is a huge project and the fact the source compiled under Raspbian says a lot about the quality of each release. I'm always so impressed by what these MAME developers do. Hopefully this issue can be identified and resolved. Perhaps some Makefile directives that get around this?

Thanks for your continued efforts in helping. I do appreciate it.
User avatar
Jun 19, 2019, 14:18
Latest update:

Thanks to George McMullen, it looks like we have a "fix" for the segfault. He discovered some differences in the the makefile from version 0.209 to 0.210 and here's his comments:

"I haven't been able to do any compilation tests yet, but I've found some changes from v0209 to v0210 which may be headed in the right direction.

In the makefile in v0210, there are two options:


But in v0209 the first is set to 0 and the second one doesn't exist (it's new in v0210). i.e.


Incidentally, these flags seem to be related to libXi. These flags are referenced in the following files:


I uncommented these new lines and everything seems to work again:


Thanks again to George for helping with this issue!
User avatar
Jun 19, 2019, 15:38
Glad it got sorted out.
The commit that changed things was here: