05551: Pete Axe Pete!, Frogger (in NTSC system), others: odyssey2 SIGABRT with clang optimizations in OS X

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	philips/odyssey2.cpp
Version	0.153	Fixed in Version	0.154	Build	Debug
		Fixed in Git Commit		Github Pull Request #

Summary	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 = 'com.apple.main-thread', 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
Github Commit

Flags
Regression Version
Affected Sets / Systems	Pete Axe Pete!, Frogger (in NTSC system), others

Attached Files

No.10644 NekoEd 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.
No.10645 wilbert Developer Apr 29, 2014, 14:35	Confirmed with an optimised clang build on my own machine
No.10646 wilbert Developer 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?