04471: Many sets using m68000-family CPU: Access Violation

ID	Category [?]	Severity [?]	Reproducibility	Date Submitted	Last Update
04471	Crash/Freeze	Critical (emulator)	Always	Aug 28, 2011, 09:32	Oct 10, 2011, 21:30

Tester	M.A.S.H.	View Status	Public	Platform	MAME (Self-compiled)
Assigned To		Resolution	Fixed	OS	Windows XP (32-bit)
Status [?]	Resolved			Driver
Version	0.143u4	Fixed in Version	0.143u7	Build	Normal
		Fixed in Git Commit		Github Pull Request #

Summary	04471: Many sets using m68000-family CPU: Access Violation
Description	Game crashes with an Access Violation
Steps To Reproduce
Additional Information	Sets in MAME which crash out wiithin 3 seconds of running aceattac - segas16b.c ad4skill - bfm_sc4.c ad5bpfpm - bfm_sc5.c ad5btc - bfm_sc5.c ad5bull - bfm_sc5.c ad5cmons - bfm_sc5.c ad5copsr - bfm_sc5.c ad5crcpt - bfm_sc5.c ad5crsc - bfm_sc5.c ad5dnd - bfm_sc5.c ad5dndcl - bfm_sc5.c ad5dnddd - bfm_sc5.c ad5dndpg - bfm_sc5.c ad5evol - bfm_sc5.c ad5eyes - bfm_sc5.c ad5gldmn - bfm_sc5.c ad5gldwn - bfm_sc5.c ad5hir - bfm_sc5.c ad5hircl - bfm_sc5.c ad5jckmo - bfm_sc5.c ad5mcob - bfm_sc5.c ad5monop - bfm_sc5.c ad5mowow - bfm_sc5.c ad5mr2r - bfm_sc5.c ad5mww - bfm_sc5.c ad5pking - bfm_sc5.c ad5pp - bfm_sc5.c ad5ppbtb - bfm_sc5.c ad5rapid - bfm_sc5.c ad5rcash - bfm_sc5.c ad5rroul - bfm_sc5.c ad5rsclb - bfm_sc5.c ad5rsnw - bfm_sc5.c ad5rspin - bfm_sc5.c ad5rsrm - bfm_sc5.c ad5rsrr - bfm_sc5.c ad5rwclb - bfm_sc5.c ad5sslam - bfm_sc5.c ad5tornc - bfm_sc5.c ad5u1337 - bfm_sc5.c ad5vlv - bfm_sc5.c ad5vpa - bfm_sc5.c altbeastj1 - segas16b.c altbeastj2 - segas16b.c cdimono1 - cdi.c endurob2 - segahang.c j5trailb - jpmsys5.c j7clbmag - jpmsys7.c maddonnb - oneshot.c megaplay - megaplay.c mg_alad - maygaysw.c mg_bb - maygaysw.c mg_gbr - maygaysw.c mg_jv - maygaysw.c mg_kf - maygaysw.c mg_lug - maygaysw.c mg_pbw - maygaysw.c mg_risk - maygaysw.c mg_scl - maygaysw.c poker52 - blitz68k.c quizard - cdi.c quizrd12 - cdi.c quizrd17 - cdi.c quizrd22 - cdi.c quizrr40 - cdi.c quizrr41 - cdi.c quizrr42 - cdi.c sc_film - bfm_sc4.c sc_unsrt - bfm_sc4.c sc4bantm - bfm_sc4.c sc4batl - bfm_sc4.c sc4bsp - bfm_sc4.c sc4cari - bfm_sc4.c sc4cblas - bfm_sc4.c sc4chain - bfm_sc4.c sc4cj - bfm_sc4.c sc4cmani - bfm_sc4.c sc4crsc - bfm_sc4.c sc4gunp - bfm_sc4.c sc4hill - bfm_sc4.c sc4hiss - bfm_sc4.c sc4hotdga - bfm_sc4.c sc4luckbz - bfm_sc4.c sc4mmad - bfm_sc4.c sc4mmm - bfm_sc4.c sc4showt - bfm_sc4.c sc4slad - bfm_sc4.c sc4sus - bfm_sc4.c sc4swbak - bfm_sc4.c sc4swywm - bfm_sc4.c sc5pogc - bfm_sc5.c shangon1 - segaorun.c step3 - stepstag.c toutrun2 - segaorun.c trisport - mcr68.c v4cmaze3c - mpu4vid.c wb35 - segas16a.c wb35a - segas16a.c westvent - astrocorp.c wwfsstarj - wwfsstar.c zoo - astrocorp.c
Github Commit

Flags
Regression Version	0.142u4
Affected Sets / Systems	Many sets using m68000-family CPU

Attached Files	trisport.png (3,419 bytes) Aug 28, 2011, 09:32 Uploaded by M.A.S.H.
Attached Files	results.txt (579,638 bytes) Aug 29, 2011, 00:11 Uploaded by Tafoid Results output for Dr. Memory and MAME 0.143u4 (trisport) [Show Content]

No.07736 Tafoid Administrator Aug 28, 2011, 12:02	Wow.. someone else is finally getting this? I thought I was a lone kook so I never reported it. MASH, could you please state your computer setup? It seems the bug is very specific to CPU processor, game main CPU and is only lurking in XP dealing only with this current toolset we started using a few months ago. MY money is on something in 68000 cpu core causing a compiler error. Confirming and added a list of games which crash in my regression tests the same way.
No.07737 Tafoid Administrator Aug 28, 2011, 12:18	My CPU is an Athlon 64 X2-4400, Windows XP (Media Edition), 2 Gig Ram. If anyone else has this crash, please state your computer stats as well (cpu/ram/OS)
No.07738 M.A.S.H. Senior Tester Aug 28, 2011, 12:59 edited on: Aug 28, 2011, 13:03	My CPU is a Intel E5200 Dual-Core (Wolfdale), Windows XP (Professional) and 2 GB RAM. Testing some games of your list, they also crashed here :(
No.07739 NekoEd Senior Tester Aug 28, 2011, 14:08 edited on: Aug 28, 2011, 14:12	SDLMAME 0.143u4 on Gentoo/x64 (vanilla 3.1.0-RC3 kernel), using GCC 4.6.1 on an Intel Core i5-2500 with 8GB RAM reporting NO crashes in any of the sets listed; everything working fine here. Build version: 0.143u4 (Aug 26 2011) Build architecure: SDLMAME_ARCH=-march=native -mfpmath=sse -mavx -maes -mpclmul Build defines 1: SDLMAME_UNIX=1 SDLMAME_X11=1 SDLMAME_LINUX=1 Build defines 1: LSB_FIRST=1 PTR64=1 DISTRO=generic SYNC_IMPLEMENTATION=tc SDL/OpenGL defines: SDL_COMPILEDVERSION=1214 USE_OPENGL=1 USE_DISPATCH_GL=1 Compiler defines A: __GNUC__=4 __GNUC_MINOR__=6 __GNUC_PATCHLEVEL__=1 __VERSION__="4.6.1" Compiler defines B: __amd64__=1 __x86_64__=1 __unix__=1 Compiler defines C: __USE_FORTIFY_LEVEL=0 Linux Tsukune 3.1.0-rc3-Tsukune-x64 #4 SMP PREEMPT Tue Aug 23 21:46:07 EDT 2011 x86_64 GNU/Linux
No.07740 Haze Senior Tester Aug 28, 2011, 15:51	a lot of the (68k) ones on that list will crash because they don't have valid code / start vectors / whatever, and the 68k crashes. For some reason the core doesn't seem very good at handling that in every case (it's still a 'bug' but many of the CPU cores aren't safe in the same situations) Out of all those listed I'd say the only ones that were a genuine concern are the CDI ones, that's meant to be a working driver. The rest, I'm not remotely surprised crash.
No.07742 NekoEd Senior Tester Aug 28, 2011, 16:18	The ones that are flagged NOT_WORKING just went to a dark screen and did nothing on my system. As for the CDi sets, and a couple of other ones (megaplay) they work as intended (in megaplay's case, it complains about not having any carts.)
No.07743 Tafoid Administrator Aug 28, 2011, 16:29	The original report included "trisport" which is a full working game - I'd call that genuine concern. Dismissing the problem because it seems to effect games technically not working is no good either. The whole list is there to assist whomever to be able to find the commonality and what in 68000 core is causing issues with these new tools and certain OS/CPU combination.
No.07744 NekoEd Senior Tester Aug 28, 2011, 17:33 edited on: Aug 28, 2011, 17:45	Tafoid has a point; the 68000 core should never jump out of it's mapped RAM space, which the ACCVIO in the attachment shows that it's doing. It would seem that somewhere along the line, the boundaries of the emulated memory space of the 68000 are lost/ignored and it's jumping to invalid places in the host machine's RAM. The question is why this is happening, and why it seems to be specifically on, as the two reports so far have shown, 32-bit Windows XP on a 64-bit x86 processor. We need more test cases; I'll try compiling a 32b version of SDLMAME, see if the problem lies in 32-on-64 in general. UPDATE: All is okay with 32b-on-64b here. Looks like it's specific to either XP32-on-64 so far; sorry I can't provide any Windows test cases....
No.07745 Haze Senior Tester Aug 28, 2011, 18:42	the 68k can jump outside address space if the program code is corrupt (which in the sets with missing / bad program roms, it is) it shouldn't crash however. I think this report is actually a combination of multiple issues, some games are crashing during normal operation, but the vast majority there are crashing because the 68k isn't running valid code. Both are bugs, but I'm not convinced they're the SAME bug. The 68k code will be changing quite a bit in the near future so the symptoms of this may change slightly, be warned.
No.07746 Haze Senior Tester Aug 28, 2011, 21:46	Fwiw Trisport is a cpu crash too, but it's meant to then reset and recover 001006: andi.w #$20, D0 00100A: bne $1016 001016: lea $1270.l, A0 00101C: jsr $4022.l 004022: move.l (A0)+, D6 004024: movea.l (A0)+, A4 004026: move.w (A0)+, (A4)+ 004028: subq.b #1, D6 00402A: bne $4026 004026: move.w (A0)+, (A4)+ 004028: subq.b #1, D6 00402A: bne $4026 (loops for 186 instructions) 00402C: rts FFFFFFFF: dc.w $ff00; opcode 1111 00843A: reset 00843C: nop 00843E: nop For some reason this code flow is capable of actually taking MAME down, either because of a bug in the CPU core, or a bug in the memory system when handling code execution from unmapped addresses on the 68k. Note, it's ended up at a 32-bit address (0xffffffff) despite the plain 68k only even having 24-bits of address space.
No.07747 NekoEd Senior Tester Aug 28, 2011, 22:06	The 68000 has only 24b of address space, however the top octet on address accesses IS present and operational; it's just ignored on the 680[01]0. This was a forward compatibility decision, and the top 8 bits of the address were officially "RESERVED TO MOTOROLA" but many (particularly Apple) ignored this and used the top octet for whatever they wanted, usually various flags or metadata. This is what lead to the entire "32b dirty/clean" debacle with early Macs when the 68020 entered the scene; that reserved portion of the addressing began to be decoded as part of the address instead of just ignored, and chaos ensued in any application (or Toolbox ROM) when 32b addressing was used. In a 680[10]0, an access to 0xFFFFFFFF should be truncated to 0x00FFFFFF; if the core is honoring/decoding the upper octet of the address on 680[01]0, there's a bug.
No.07748 R. Belmont Developer Aug 28, 2011, 22:08	Just for the record, the emulated 68k cannot "jump outside the boundries of the emulated space" and "jumping to invalid places in the host machine's RAM". That is nonsense on stilts and makes me want to ignore MAMETesters even harder than I do usually.
No.07749 NekoEd Senior Tester Aug 28, 2011, 22:37	Well, SOMETHING tried to read the host machine's RAM at address 0x8, which is what caused the ACCVIO (and rightfully so, it's only 0x8 off of a null pointer dereference.)
No.07750 Tafoid Administrator Aug 29, 2011, 00:10	Added a run through "Dr. Memory" which is supposed to be a valgrind-ish type of analysis tool for errors.
No.07751 NekoEd Senior Tester Aug 29, 2011, 03:00	Found the ACCVIO in that list, it's #394: Error #394: UNADDRESSABLE ACCESS: reading 0x00000008-0x0000000c 4 byte(s) @0:00:30.359 in thread 1012 0x77c3554a <msvcrt.dll+0x2554a> msvcrt.dll!abnormal_termination ??:0
No.07761 Haze Senior Tester Aug 31, 2011, 14:44	Pretty sure this is a compiler / toolchain bug, the current toolchain is very buggy. Hopefully it will be replaced with something more reliable soonish.
No.07825 Tafoid Administrator Oct 10, 2011, 21:30	Fixed by Sandro Ronco