|
mame 0152 running on ARM produces segmentation fault
#321744 - 02/09/14 11:33 PM
|
|
|
Hi,
I compiled mame 0152 on my ARM linux machine. The program was compiled and linked fine.
When I run it I got a Segmentation fault (please see attached log).
I compiled like this: make OSD=osdmini SUBTARGET=tiny OPTIMIZE=0 DEBUG=1 SYMBOLS=1
I didn't specify any extra compiler nor linker options in the make file - I left everything in default
(there were a few unresolved linking problems but nothing major)
I'm using gcc 4.6 and the linux is Ubuntu 12.04.
Any clues or suggestions how to fix it?
Cheers!
Ole
---- the crash log follows -----
developer@ouya:~/fun/dev/mame0152$ gdb ./mametinyd
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
Copyright (C) 2012 Free Software Foundation, Inc.
...
This GDB was configured as "arm-linux-gnueabihf".
...
Reading symbols from /home/developer/fun/dev/mame0152/mametinyd...done.
(gdb) run -rompath ./roms hardhat
Starting program: /home/developer/fun/dev/mame0152/mametinyd -rompath ./roms hardhat
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
0x001e1312 in delegate_mfp::convert_to_generic (this=0xbe9c2fac, object=@0xbe9c2f9c: 0xbe9c6790)
at src/emu/delegate.c:50
50 return *reinterpret_cast(vtable_base + m_function - 1);
(gdb) bt
#0 0x001e1312 in delegate_mfp::convert_to_generic (this=0xbe9c2fac, object=@0xbe9c2f9c: 0xbe9c6790)
at src/emu/delegate.c:50
#1 0x00019554 in delegate_mfp::update_after_bind (this=0xbe9c2fac,
funcptr=@0xbe9c2f98: 0, object=@0xbe9c2f9c: 0xbe9c6790) at src/emu/delegate.h:379
#2 0x00019152 in delegate_base::bind (
this=0xbe9c2f98, object=0xbe9c6790) at src/emu/delegate.h:553
#3 0x002e5ad6 in delegate_base::delegate_base (this=0xbe9c2f98, funcptr=
(void (device_scheduler::*)(device_scheduler * const)) 0x2e440d ,
name=0x4ed8e0 "device_scheduler::presave", object=0xbe9c6790) at src/emu/delegate.h:460
#4 0x002e5560 in delegate::delegate(delegate_base::traits::member_func_type, const char *, device_scheduler *)
(this=0xbe9c2f98, funcptr=
(void (device_scheduler::*)(device_scheduler * const)) 0x2e440d ,
name=0x4ed8e0 "device_scheduler::presave", object=0xbe9c6790) at src/emu/delegate.h:587
#5 0x002e3958 in device_scheduler::device_scheduler (this=0xbe9c6790, machine=...)
at src/emu/schedule.c:333
#6 0x00288a48 in running_machine::running_machine (this=0xbe9c30a0, _config=..., osd=...,
exit_to_game_select=false) at src/emu/machine.c:173
#7 0x00287e04 in mame_execute (options=..., osd=...) at src/emu/mame.c:192
#8 0x001da510 in cli_frontend::execute (this=0xbe9c7074, argc=4, argv=0xbe9c7314)
at src/emu/clifront.c:226
#9 0x00063830 in main (argc=4, argv=0xbe9c7314) at src/osd/osdmini/minimain.c:68
--- end of the log ---
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9713
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: mame 0152 running on ARM produces segmentation fault
[Re: ole]
#321792 - 02/10/14 08:16 PM
|
|
|
> I'm using gcc 4.6 and the linux is Ubuntu 12.04.
>
> Any clues or suggestions how to fix it?
None of the devs has a reliable ARM debugging environment so at this point we can only support compiling/linking on e.g. ARM Linux. Making it run is up to someone with such a setup.
|
|
|
|
Re: mame 0152 running on ARM produces segmentation fault
[Re: ole]
#321843 - 02/11/14 10:58 PM
|
|
|
Try this, in the file src/emu/delegate.h find the lines
#if defined(__GNUC__)
#define USE_DELEGATE_TYPE DELEGATE_TYPE_INTERNAL
#else
#define USE_DELEGATE_TYPE DELEGATE_TYPE_COMPATIBLE
#endif
and substitute them with the line
#define USE_DELEGATE_TYPE DELEGATE_TYPE_COMPATIBLE
then recompile everything and see if it works.
|
|
|
|
Re: mame 0152 running on ARM produces segmentation fault
[Re: ole]
#321866 - 02/12/14 10:34 AM
|
|
|
Just as a heads-up, given the OOOOH-YEEEEEAH's utterly anemic CPU, you're not going to have a remotely good time running MAME on it. This goes double unless you're willing to spend the time to make an OSD layer that targets OpenGL ES for the final screen blit, as otherwise you're going to be doing it in software, which will make things even slower than they already will be.
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9713
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: mame 0152 running on ARM produces segmentation fault
[Re: MooglyGuy]
#321869 - 02/12/14 05:51 PM
|
|
|
> Just as a heads-up, given the OOOOH-YEEEEEAH's utterly anemic CPU, you're not going
> to have a remotely good time running MAME on it. This goes double unless you're
> willing to spend the time to make an OSD layer that targets OpenGL ES for the final
> screen blit, as otherwise you're going to be doing it in software, which will make
> things even slower than they already will be.
It should be sufficient for Pac-Man, but yeah, Ouya apparently got reject-bin CPUs from Nvidia or something because they bench far slower than the allegedly identical parts in the Nexus 7.
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9713
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: mame 0152 running on ARM produces segmentation fault
[Re: sz72]
#321870 - 02/12/14 05:52 PM
|
|
|
It's not that, it's pointer alignment in the memory system. I keep trying to get someone who understands the memory system internals to pay attention to this issue and they continue to ignore it.
|
|
|
|
Re: mame 0152 running on ARM produces segmentation fault
[Re: sz72]
#322058 - 02/16/14 03:28 AM
|
|
|
Hi,
Thanks for the tip. I did what you suggested and I got quite further. I had another issue with the build, but it seems it's resolved now.
Mame aborted on the following assertion:
FATALERROR: assert: src/emu/emualloc.c:269: entry != NULL
setting breakpoint on the assert and running gdb revealed this:
(gdb)
resource_pool::add (this=0xbefd70d0, item=...) at src/emu/emualloc.c:269
269 assert(entry != NULL);
(gdb) bt
#0 resource_pool::add (this=0xbefd70d0, item=...) at src/emu/emualloc.c:269
#1 0x002d4eca in resource_pool::add_array (this=0xbefd70d0, array=0x107eb50, count=256)
at src/emu/emualloc.h:266
#2 0x002d3b3c in render_font::load_cached (this=0x107d5d8, file=..., hash=0) at src/emu/rendfont.c:601
#3 0x002d241a in render_font::render_font (this=0x107d5d8, manager=..., filename=0x4ec86c "ui.bdf")
at src/emu/rendfont.c:116
#4 0x002cdafa in render_manager::font_alloc (this=0x8fe7f8, filename=0x8eed40 "default")
at src/emu/render.c:2583
#5 0x00301396 in ui_get_font (machine=...) at src/emu/ui.c:476
#6 0x003013c6 in ui_get_line_height (machine=...) at src/emu/ui.c:488
#7 0x00301d80 in ui_draw_text_box (container=0x40370008, text=0x884a08 "Initializing...", justify=0, xpos=0.5,
ypos=0.5, backcolor=4010807344) at src/emu/ui.c:788
#8 0x00303090 in handler_messagebox (machine=..., container=0x40370008, state=0) at src/emu/ui.c:1218
#9 0x003011a8 in ui_update_and_render (machine=..., container=0x40370008) at src/emu/ui.c:439
#10 0x00321ebc in video_manager::frame_update (this=0x9006b8, debug=false) at src/emu/video.c:212
#11 0x00301076 in ui_set_startup_text (machine=..., text=0x4e504c "Initializing...", force=1)
at src/emu/ui.c:406
#12 0x0028c834 in running_machine::start (this=0xbefd70d0) at src/emu/machine.c:310
#13 0x0028ce3c in running_machine::run (this=0xbefd70d0, firstrun=true) at src/emu/machine.c:384
#14 0x0028b060 in mame_execute (options=..., osd=...) at src/emu/mame.c:202
That looked quite promising. The ui_draw_text_box tries to render "Initializing...". To do that it needs to load the "default" font and eventually fails
to use embedded font. I had a look at the resource_pool::add() and the memory_entry::find() and found out that all memory pointers (entry->m_base) in the
memory pool are aligned to 8 bytes. In resource_pool::add() there is a "safety" search to the "address - 4" if the first search fails. As the addresses
on my system are aligned to 8 bytes I changed the safety search to "address - 8" and then it all started to work. I could see the mini_osd_interface::update()
started ticking regularly and width and height of the screen was set to 256.
So far it seems the "safety find" was required only once (in the glyph allocation), the rest of the find()'s were spot on. This is not a proper fix though, as
the magic number 8 has to have some reasonable explanation (which I don't have). Or at least the size should be detected in runtime. Thanks again.
Ole
|
|
|
|
Re: mame 0152 running on ARM produces segmentation fault
[Re: MooglyGuy]
#322061 - 02/16/14 03:56 AM
|
|
|
Yes, I was able to run an older version of mame (0125) on ouya linux (4 cores at 1.6 Gigs Arm Cortex-A9). As you wrote I had to make the EGL2/Alsa osd port and managed to squeeze some reasonable framerates using multi-threaded rendering. The biggest bottleneck seems to be the graphics (not the emulation itself), no-frame-skipping works only on 720p, anything higher than that has speed penalty. Also pixel shaders slow down the rendering quite a lot. Anyway it is good enough for my p47 board emulation (2 x m68000), sonicwings, darkseal and others to run without hiccups (full speed framerates in 720p vsynced).
Tegra 3 is now obsolete, but there are other faster ARM processors on the horizon (tegra4 is available - Tegra note - relatively cheap device, Linux drivers with hardware accleration are available for T4 as well). So I think it's worth to have an up-to-date mame version runing on ARM.
Ole
Edit: typos
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9713
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: mame 0152 running on ARM produces segmentation fault
[Re: ole]
#322188 - 02/18/14 05:47 PM
|
|
|
> the rest of the find()'s were spot on. This is not a proper fix though, as
> the magic number 8 has to have some reasonable explanation (which I don't have). Or
> at least the size should be detected in runtime. Thanks again.
As noted, I have personally been trying to get an explanation of that whole safety find mechanism for years now...
ETA: The explanation is that resource pools are an outdated concept now that everything has been converted to C++ and they'll be going away, but it's going to take time. Aaron specifically says "do what you have to to make it run, but don't spend a lot of time on it".
Edited by R. Belmont (02/18/14 07:00 PM)
|
|
|
|
Re: mame 0152 running on ARM produces segmentation fault
[Re: R. Belmont]
#322213 - 02/19/14 12:51 AM
|
|
|
> As noted, I have personally been trying to get an explanation of that whole safety
> find mechanism for years now...
My previous post was not meant as a criticism, just an explanation of the finding I encountered in a hope it may be useful to other (ARM) porters. I have a hunch the public ARM port that Seleuco maintains may be stuck on version 0139 for a similar reason that I tried to resolve in the first place (0139 is the last version that doesn't use delegate.c), but I might be wrong of course.
|
|
|
|
Re: mame 0152 running on ARM produces segmentation fault
[Re: R. Belmont]
#322283 - 02/20/14 04:55 AM
|
|
|
> > the rest of the find()'s were spot on. This is not a proper fix though, as
> > the magic number 8 has to have some reasonable explanation (which I don't have). Or
> > at least the size should be detected in runtime. Thanks again.
>
> As noted, I have personally been trying to get an explanation of that whole safety
> find mechanism for years now...
I wasn't the one to add it, but I can explain why it works.
MAME's font subsystem uses new [] to allocate an array of glyphs. glyph has non-trivial destructor, so g++ inserts an array cookie in front of the array. Internally, g++ emits code like this:
Code:
void *p1 = operator new[](size + cookie_size, ...)
type *p2 = (type *)((char *)p1 + cookie_size);
// set cookie at p1, then construct all elements of p2 in-place
return p2;
The trick is that MAME sets up the array's memory_entry *inside* its custom allocator (i.e., for p1) but later tries to look up p2. Normally the cookie is sizeof(size_t) bytes, so on failure you can just back up sizeof(size_t) bytes and try again.
This blows up on 32-bit ARM, where sizeof(size_t) == 4 and the ARM C++ ABI specifies an 8-byte array cookie. It could also blow up on other platforms if g++ ever needs to add padding after the array cookie, but that only happens if alignof(type) > sizeof(size_t) which is pretty unlikely (and IIRC impossible on most platforms).
Technically resource_pool is relying on non-portable behavior, but fixing it the "right" way would mean rearranging a bunch of the memory allocation code so that the memory_entry gets populated after g++ fixes up the pointer. Or just do the simple workaround -- add an ARM-specific #ifdef that uses 8 instead of sizeof(size_t), and cross your fingers that g++ never needs padding on other platforms.
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9713
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: mame 0152 running on ARM produces segmentation fault
[Re: AnonymousDeveloper]
#322315 - 02/20/14 06:20 PM
|
|
|
(awesomeness snipped, read his post for details)
> Technically resource_pool is relying on non-portable behavior, but fixing it the
> "right" way would mean rearranging a bunch of the memory allocation code so that the
> memory_entry gets populated after g++ fixes up the pointer. Or just do the simple
> workaround -- add an ARM-specific #ifdef that uses 8 instead of sizeof(size_t), and
> cross your fingers that g++ never needs padding on other platforms.
Fantastic! This should be able to get us moving forward again on ARM. Now where'd I put my ARM OLPC? 
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9713
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: mame 0152 running on ARM produces segmentation fault
[Re: AnonymousDeveloper]
#323214 - 03/11/14 06:09 PM
|
|
|
> Technically resource_pool is relying on non-portable behavior, but fixing it the
> "right" way would mean rearranging a bunch of the memory allocation code so that the
> memory_entry gets populated after g++ fixes up the pointer. Or just do the simple
> workaround -- add an ARM-specific #ifdef that uses 8 instead of sizeof(size_t), and
> cross your fingers that g++ never needs padding on other platforms.
resource_pool just went away entirely, so 0.153 should be safe for ARM.
|
|
|
|
Re: mame 0152 running on ARM produces segmentation fault
[Re: ole]
#323270 - 03/13/14 12:42 AM
|
|
|
I had the same pb when porting 0.151 to android using standalone toolchain (r8 and r9).
Some wise dev point me a fix for ARM port for
delegate.c & emualloc.c .
for emmullaoc.c in resource_pool::add
Code:
if (entry == NULL)
#ifdef USE_ARM_HACK
entry = memory_entry::find(reinterpret_cast(item.m_ptr) - 8);
#else
entry = memory_entry::find(reinterpret_cast(item.m_ptr) - sizeof(size_t));
#endif
and in delegate_mfp::convert_to_generic
Code:
#ifdef USE_ARM_HACK
object = reinterpret_cast(reinterpret_cast(object));
if (!(m_this_delta))
return reinterpret_cast(m_function);
UINT8 *vtable_base = *reinterpret_cast(object);
return *reinterpret_cast(vtable_base + m_function);
#else
with this patch , i was able to compile and execute fine on android .
anyways , Great if it will be not needed with 0.153 and then more ARM friendly .
|
|
|
Previous 
Index 
Next 
Threaded 
mame 0152 running on ARM produces segmentation fault
Reply
[Re: 
