Viewing Issue Advanced Details
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
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
Regression Version 0.142u4
Affected Sets / Systems Many sets using m68000-family CPU
Attached Files
png file icon trisport.png (3,419 bytes) Aug 28, 2011, 09:32 Uploaded by M.A.S.H.
txt file icon 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]
There are no relationsihp linked to this issue.
User avatar
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.
User avatar
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)
User avatar
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 :(

User avatar
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: LSB_FIRST=1 PTR64=1 DISTRO=generic SYNC_IMPLEMENTATION=tc
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

User avatar
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.
User avatar
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.)
User avatar
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.
User avatar
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....

User avatar
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.
User avatar
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.
User avatar
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.
User avatar
R. Belmont
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.
User avatar
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.)
User avatar
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.
User avatar
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
User avatar
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.
User avatar
Oct 10, 2011, 21:30
Fixed by Sandro Ronco