Viewing Issue Advanced Details
ID Category [?] Severity [?] Reproducibility Date Submitted Last Update
05551 Crash/Freeze Minor Always Apr 26, 2014, 17:41 Apr 29, 2014, 22:42
Tester fernandotcl View Status Public Platform MESS (Self-compiled)
Assigned To wilbert Resolution Fixed OS MacOS X
Status [?] Resolved Driver odyssey2.cpp
Version 0.153 Fixed in Version 0.154 Build Debug
Summary MESS-specific 05551: Pete Axe Pete!, Frogger (in NTSC system), others: odyssey2 SIGABRT with clang optimizations in OS X
Description Using MESS 0.153 or git revision 402ffe9a, if OPTIMIZE is set to anything but 0, I can make MESS crash consistently with SIGABRT.
Steps To Reproduce There's at least two ways to reproduce this, both using "odyssey2" as the system:

1. Videopac 43 (Pick Axe Pete) crashes whenever you manage to enter a door (which you can do once you get the key). MESS crashes before the animation between levels is shown.

2. Parker Brothers' Frogger crashes after the intro when using the NTSC console (odyssey2 instead of Videopac). That game is a PAL game, so it should be rendered with glitches, but instead MESS just crashes. Note that the Brazilian version of Frogger doesn't crash (it's compatible with NTSC consoles).

2 is much easier to reproduce, as you don't even have to play the game. :-)
Additional Information Digging deeper into the problem, I realized it's related to the optimization level. If OPTIMIZE is set to 0, MESS doesn't crash anymore. It's NOT, however, related to -fno-strict-aliasing (which is normally enabled when OPTIMIZE isn't 0), as MESS crashes with OPTIMIZE set to 1 and that line commented out.

Compiling with DEBUG and SYMBOLS, the backtrace isn't that interesting:

* thread #1: tid = 0x22c04, 0x00007fff91f2c866 libsystem_kernel.dylib`__pthread_kill + 10, queue = '', stop reason = signal SIGABRT
  * frame #0: 0x00007fff91f2c866 libsystem_kernel.dylib`__pthread_kill + 10
    frame #1: 0x00007fff94e8135c libsystem_pthread.dylib`pthread_kill + 92
    frame #2: 0x00007fff9258ebba libsystem_c.dylib`__abort + 145
    frame #3: 0x00007fff9258f46d libsystem_c.dylib`__stack_chk_fail + 196
    frame #4: 0x000000010004d053 messtiny64d`i8244_device::render_scanline(this=<unavailable>, vpos=<unavailable>) + 3267 at i8244.c:721
    frame #5: 0x000000010013dc05 messtiny64d`device_scheduler::execute_timers(this=0x00007fff5fbfd7b8) + 245 at schedule.c:900
    frame #6: 0x00000001000f830f messtiny64d`running_machine::run(this=0x00007fff5fbf6ea0, firstrun=<unavailable>) + 431 at machine.c:381
    frame #7: 0x00000001000f5fb6 messtiny64d`mame_execute(options=0x00007fff5fbfe8e8, osd=0x00007fff5fbfeb08) + 406 at mame.c:162
    frame #8: 0x000000010005901e messtiny64d`cli_frontend::execute(this=0x00007fff5fbfe8c8, argc=<unavailable>, argv=<unavailable>) + 2078 at clifront.c:237
    frame #9: 0x000000010000b22f messtiny64d`SDL_main(argc=7, argv=0x000000010090b880) + 143 at sdlmain.c:379
    frame #10: 0x000000010000a971 messtiny64d`-[SDLMain applicationDidFinishLaunching:](self=<unavailable>, _cmd=<unavailable>, note=<unavailable>) + 49 at SDLMain_tmpl.m:304
    frame #11: 0x00007fff8d116e0c CoreFoundation`__CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 12
    frame #12: 0x00007fff8d00aa6d CoreFoundation`_CFXNotificationPost + 2893
    frame #13: 0x00007fff92ded7ba Foundation`-[NSNotificationCenter postNotificationName:object:userInfo:] + 68
    frame #14: 0x00007fff8aa98cf9 AppKit`-[NSApplication _postDidFinishNotification] + 289
    frame #15: 0x00007fff8aa98a2c AppKit`-[NSApplication _sendFinishLaunchingNotification] + 195
    frame #16: 0x00007fff8aa95916 AppKit`-[NSApplication(NSAppleEventHandling) _handleAEOpenEvent:] + 570
    frame #17: 0x00007fff8aa9536b AppKit`-[NSApplication(NSAppleEventHandling) _handleCoreEvent:withReplyEvent:] + 242
    frame #18: 0x00007fff92e0bf0a Foundation`-[NSAppleEventManager dispatchRawAppleEvent:withRawReply:handlerRefCon:] + 294
    frame #19: 0x00007fff92e0bd7d Foundation`_NSAppleEventManagerGenericHandler + 106
    frame #20: 0x00007fff9348ee1f AE`aeDispatchAppleEvent(AEDesc const*, AEDesc*, unsigned int, unsigned char*) + 381
    frame #21: 0x00007fff9348ec32 AE`dispatchEventAndSendReply(AEDesc const*, AEDesc*) + 31
    frame #22: 0x00007fff9348eb36 AE`aeProcessAppleEvent + 315
    frame #23: 0x00007fff93ab7161 HIToolbox`AEProcessAppleEvent + 56
    frame #24: 0x00007fff8aa91246 AppKit`_DPSNextEvent + 1026
    frame #25: 0x00007fff8aa90a2b AppKit`-[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 122
    frame #26: 0x00007fff8aa84b2c AppKit`-[NSApplication run] + 553
    frame #27: 0x000000010000ac7e messtiny64d`CustomApplicationMain(argc=<unavailable>, argv=<unavailable>) + 286 at SDLMain_tmpl.m:231
    frame #28: 0x000000010000ab47 messtiny64d`main(argc=<unavailable>, argv=<unavailable>) + 183 at SDLMain_tmpl.m:382

Line 721 is the closing brace for render_scanline, btw.

A workaround would be to detect clang and set the optimization level to 0. I have no idea if this affects other emulated systems or if it's just a bug in the odyssey2 driver.

This is my compiler:

$ clang -v
Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin13.1.0
Thread model: posix
Regression Version
Affected Sets / Systems Pete Axe Pete!, Frogger (in NTSC system), others
Attached Files
There are no relationsihp linked to this issue.
User avatar
Senior Tester
Apr 28, 2014, 23:04
How hard is it to get a key? If it takes longer than a trivial amount of time, an input record or savestate would aid in testing.
User avatar
Apr 29, 2014, 14:35
Confirmed with an optimised clang build on my own machine
User avatar
Apr 29, 2014, 14:58
I have just committed a fix in subversion.

If you are in the position to do so, could you confirm that latest svn fixes the issue for you?