Viewing Issue Advanced Details
ID Category [?] Severity [?] Reproducibility Date Submitted Last Update
02104 Crash/Freeze Critical (emulator) Always Aug 9, 2008, 22:10 Jan 2, 2009, 16:56
Tester Pugsy View Status Public Platform MAME (Self-compiled)
Assigned To aaron Resolution Fixed OS Windows 2000
Status [?] Resolved Driver namcos2.cpp
Version 0.126u4 Fixed in Version 0.129 Build Normal
Summary 02104: metlhawk, metlhawkj: Crash while decoding with '-debug' trigger
Description Starting a regular build of MAME with the debugger (-debug) causes a crash while the "Decoding XX %" message is up.
Unable to reproduce in a debug build or symbols build with the -debug flag.

-----------------------------------------------------
Exception at EIP=00996CD6: ACCESS VIOLATION
While attempting to read memory at 05104040
-----------------------------------------------------
EAX=00000000 EBX=00000010 ECX=05104040 EDX=00000010
ESI=00000000 EDI=0BD60360 EBP=0022F448 ESP=0022F370
Steps To Reproduce
Additional Information Might be related to 00284?
Flags
Regression Version
Affected Sets / Systems metlhawk, metlhawkj
Attached Files
? file icon tilemap.diff (980 bytes) Jan 2, 2009, 10:06
[Show Content]
zip file icon valgrind_7759.zip (3,325 bytes) Jan 2, 2009, 15:31
Relationships
There are no relationship linked to this issue.
Notes
21
User avatar
No.02021
Tafoid
Administrator
Aug 10, 2008, 00:29
Confirmed on Windows only - SDLMAME reports this not happening.
User avatar
No.02316
ShimaPong
Tester
Sep 3, 2008, 14:35
I can't confirm mame 0.127 downloaded from mamedev.
metlhawk, metlhwkj work fine with the debugger.
User avatar
No.02317
Tafoid
Administrator
Sep 3, 2008, 14:59
Still crashes here, normal 32-bit build: mame metlhawk -debug
User avatar
No.02328
ShimaPong
Tester
Sep 4, 2008, 14:27
I can't confirm at all.

- Run on Windows ME
- Downloaded archive from dev is mame0127b.exe (CRC : EB9D9B92)
- Started with "mame metlhawk -debug"

Any crash doesn't happen during MAME boot.
User avatar
No.02329
Fujix
Administrator
Sep 4, 2008, 14:49
edited on: Sep 4, 2008, 14:50
My result in u1 with xp:

C:\mame>mame metlhawk -debug
ampal16l8a-sys87b-1.4g NOT FOUND (NO GOOD DUMP KNOWN)
ampal16l8a-sys87b-2.5e NOT FOUND (NO GOOD DUMP KNOWN)
WARNING: the game might not run correctly.

-----------------------------------------------------
Exception at EIP=009A23D7: ACCESS VIOLATION
While attempting to read memory at 05B34040
-----------------------------------------------------
EAX=00000000 EBX=00000000 ECX=05B34040 EDX=00000010
ESI=0C6D0360 EDI=00000000 EBP=0023F448 ESP=0023F390

C:\mame>

Windows Me is not recommended for testing.
User avatar
No.02333
ShimaPong
Tester
Sep 4, 2008, 17:08
> Windows Me is not recommended for testing.

I understand that you want to stop me reporting a bug as long as recommended system.
OK, I cut any new report out.
User avatar
No.02334
Fujix
Administrator
Sep 4, 2008, 18:22
They are not banned to be used for testing.

I'd like you to take account of the possibility of Windows 9x to cause another problem.
User avatar
No.02337
aaron
Developer
Sep 4, 2008, 19:47
I was not able to repro this either.
User avatar
No.02340
Fujix
Administrator
Sep 4, 2008, 21:20
I tested on Vista 64-bit, the bug doesn't reproduce.
And I made a symbol build and tested on 32-bit XP, the game works without crashing.

Seems it is only in a non-symbol build on 32-bit.
User avatar
No.03463
Firewave
Senior Tester
Jan 2, 2009, 03:03
edited on: Jan 2, 2009, 15:32
I can reproduce this with the official 0.128 binary on Windows XP x64.

UPDATE: And here is the crash information using a OPTIMIZE=3 SYMBOLS=1 build of 0.128u7:

-----------------------------------------------------
Exception at EIP=0095F862 (tilemap_scan_cols_flip_xy+0x038a): ACCESS VIOLATION
While attempting to read memory at 0A7B4040
-----------------------------------------------------
EAX=00000000 EBX=00000000 ECX=0A7B4040 EDX=00000000
ESI=00000010 EDI=115B0360 EBP=0022F538 ESP=0022F470

If the function is right, it might actually help. I can't get it to crash within gdb though.
User avatar
No.03465
aaron
Developer
Jan 2, 2009, 03:59
Still no dice. That's a bogus reference, the function tilemap_scan_cols_flip_xy is too short to have that offset. Unless we can repro with the most recent build, I'm leaning toward resolving this no repro.
User avatar
No.03470
Tafoid
Administrator
Jan 2, 2009, 04:22
I'm not sure what to say - MAME metlhawk -debug still crashes for me in 0.128u7. All attempts past and present to get a symbols/debug or both build to replicate a crash has failed.
User avatar
No.03471
aaron
Developer
Jan 2, 2009, 04:45
Does this binary crash for you?
http://aarongiles.com/test/mame-atitest.zip

(Copy & paste URL, direct link won't work)

I compiled it with standard tools from latest bits, no options (just mingw32-make -j3). With that binary, I have no problems.
User avatar
No.03474
Tafoid
Administrator
Jan 2, 2009, 05:05
edited on: Jan 2, 2009, 05:06
Crashes with this build. My video recording of the event is here:
http://mameload.mameworld.info/metlhawk_crash.zip
User avatar
No.03475
Firewave
Senior Tester
Jan 2, 2009, 05:25
The test binary still crashes for me as well.
User avatar
No.03476
Firewave
Senior Tester
Jan 2, 2009, 07:00
The .map information seems to be at least vaguely correct. valgrind shows a lot of uninitialised memory usage involving tilemap_create() in src/drivers/namcoic.c.

Here just the first entry of the log:

==7759== Conditional jump or move depends on uninitialised value(s)
==7759==    at 0x86D82F4: tilemap_create (tilemap.c:524)
==7759==    by 0x83002DA: namco_tilemap_init (namcoic.c:65)
==7759==    by 0x8311FA5: video_start_metlhawk (namcos2.c:472)
==7759==    by 0x86AF88E: mame_execute (mame.c:1558)
==7759==    by 0x8679434: cli_execute (clifront.c:171)
==7759==    by 0x86477BE: main (sdlmain.c:386)
==7759==  Uninitialised value was created by a heap allocation
==7759==    at 0x4028D3E: malloc (vg_replace_malloc.c:207)
==7759==    by 0x86CDF05: malloc_or_die_file_line (restrack.c:76)
==7759==    by 0x86D82D2: tilemap_create (tilemap.c:340)
==7759==    by 0x83002DA: namco_tilemap_init (namcoic.c:65)
==7759==    by 0x8311FA5: video_start_metlhawk (namcos2.c:472)
==7759==    by 0x86AF88E: mame_execute (mame.c:1558)
==7759==    by 0x8679434: cli_execute (clifront.c:171)
==7759==    by 0x86477BE: main (sdlmain.c:386)

Maybe the gfx layout or the memory map is bogus...
User avatar
No.03477
aaron
Developer
Jan 2, 2009, 10:06
I doubt those warnings are the cause. Regardless, I'm attaching a diff that fixes this particular valgrind complaint. Let me know if it makes any difference.
User avatar
No.03479
Fujix
Administrator
Jan 2, 2009, 11:26
I applied the diff file but it still have the crash for me.
M:\mame>mame -debug metlhawk
ampal16l8a-sys87b-1.4g NOT FOUND (NO GOOD DUMP KNOWN)
ampal16l8a-sys87b-2.5e NOT FOUND (NO GOOD DUMP KNOWN)
WARNING: the game might not run correctly.

-----------------------------------------------------
Exception at EIP=009E44B7: ACCESS VIOLATION
While attempting to read memory at 057D4040
-----------------------------------------------------
EAX=00000000 EBX=00000000 ECX=057D4040 EDX=00000010
ESI=0C5D0020 EDI=00000000 EBP=0023F5A8 ESP=0023F4E0
User avatar
No.03481
RansAckeR
Tester
Jan 2, 2009, 13:12
edited on: Jan 2, 2009, 13:13
I tested some versions from 0.126 to 0.128u7 and also http://aarongiles.com/test/mame-atitest.zip and I also get the crash:

C:\emu\mame>mame.exe metlhawk -debug
ampal16l8a-sys87b-1.4g NOT FOUND (NO GOOD DUMP KNOWN)
ampal16l8a-sys87b-2.5e NOT FOUND (NO GOOD DUMP KNOWN)
WARNING: the game might not run correctly.

-----------------------------------------------------
Exception at EIP=0098C426: ACCESS VIOLATION
While attempting to read memory at 05164020
-----------------------------------------------------
EAX=00000000 EBX=00000010 ECX=05164020 EDX=00000010
ESI=00000000 EDI=0BDD0460 EBP=0022F448 ESP=0022F370
User avatar
No.03482
Firewave
Senior Tester
Jan 2, 2009, 15:33
edited on: Jan 2, 2009, 15:34
I attached the whole valgrind log until the debugger window shows up (that's without the attached fix applied).
User avatar
No.03483
aaron
Developer
Jan 2, 2009, 16:56
Thanks, that helped. I was able to repro the problem finally by forcing auto_malloc() to randomize its memory in debug builds. It used to do this but that accidentally got removed a few versions ago and so we were seeing wide system variances in behavior.