| ID | Category [?] | Severity [?] | Reproducibility | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 02734 | Crash/Freeze | Critical (emulator) | Always | Dec 11, 2008, 19:54 | Nov 16, 2009, 20:33 |
| Tester | Radwar | View Status | Public | Platform | MAME (Self-compiled) |
| Assigned To | Firewave | Resolution | Fixed | OS | |
| Status [?] | Resolved | Driver | |||
| Version | 0.128u5 | Fixed in Version | 0.135u1 | Build | I686 |
| Fixed in Git Commit | Github Pull Request # | ||||
| Summary | 02734: videocba, videodad, blckjack: Crash immediately after OK | ||||
| Description | Only babydad and babypkr don't crash except they have graphical issues (as seen in the screenshots) that weren't present before (don't know which version, though but my original screenshots show that they were fine before). | ||||
| Steps To Reproduce | |||||
| Additional Information |
Backtrace from 0.129u3 (SYMBOLS=1 OPTIMIZE=3)Program received signal SIGSEGV, Segmentation fault. |
||||
| Github Commit | |||||
| Flags | |||||
| Regression Version | 0.128u4 | ||||
| Affected Sets / Systems | videocba, videodad, blckjack | ||||
|
Attached Files
|
 babydad.png (4,028 bytes) Dec 11, 2008, 19:54 | ||||
| babypkr.png (3,623 bytes) Dec 11, 2008, 19:55 | |||||
 No.03279
etabeta Developer
Dec 11, 2008, 20:32
edited on: Dec 11, 2008, 20:32
|
crash not confirmed here. I can play videopkr with no issues. |
|---|---|
|
No.03280
Radwar Tester
Dec 11, 2008, 21:53
|
Really? I deleted the nvram and cfg but to no avail. I'm using the MAME version released at EmuFrance, usually they're pretty reliable, so I don't know. |
 No.03281
Tafoid Administrator
Dec 11, 2008, 22:29
|
videopkr plays ok for me as well, but the other 3 sets mentioned crash after OK. I'll have to build a symbols version to find out what's up. |
|
No.03282
Radwar Tester
Dec 11, 2008, 22:49
|
Do you guys get graphics problems in babydad and babypkr aswell? |
|
No.03283
Tafoid Administrator
Dec 11, 2008, 23:11
|
Yes, I can confirm the graphic regression as well - likely related. Last time any of these seemed to work is 0.128u3. I also cannot seem to get symbols build to crash for me on any of those listed sets - so I can produce no backtrace. |
|
No.03489
Firewave Senior Tester
Jan 3, 2009, 00:39
|
I was able to reproduce the videocba crash (OPTIMIZE=3 SYMBOLS=1 build) with 0.128u7:----------------------------------------------------- Exception at EIP=0095AC64 (memory_write_byte_8le+0x0010): ACCESS VIOLATION While attempting to read memory at 0000007C ----------------------------------------------------- EAX=00000000 EBX=00000000 ECX=00000102 EDX=0000002A ESI=0022FD78 EDI=00000000 EBP=0022FCF8 ESP=0022FCEC Unfortunately on information and crash in SDLMAME. |
|
No.03528
Firewave Senior Tester
Jan 8, 2009, 04:06
|
I am getting a crash with babydad, blckjack, videocba, and videopkr using the official 0.129 binary. |
|
No.03723
Tafoid Administrator
Feb 5, 2009, 02:10
edited on: Feb 5, 2009, 02:13
|
As near as I've been able to test - compilations made on an AMD seem to crash for those sets on AMD and PENTIUM CPUS. I made an OPTIMIZE=2 build and the games ran fine again. It then built a "SYMBOLS=1 OPTIMIZE=3" build (Firewave mentions above) and I get the crash + a back trace which I've put in the additional information. It's a very odd bug which seems to only effect AMD built compiles with OPTIMIZE=3. |
|
No.04717
Firewave Senior Tester
Jul 27, 2009, 00:06
|
The stuff I get in gdb with the official 0.133 binary:Program received signal SIGSEGV, Segmentation fault. 0x00a62e8d in ?? () (gdb) bt #0 0x00a62e8d in ?? () #1 0xad202020 in ?? () #2 0x076d3300 in ?? () #3 0x0022fdb8 in ?? () #4 0x06315378 in ?? () #5 0x0022fd38 in ?? () #6 0x00e0440f in ?? () #7 0xbaadf00d in ?? () #8 0x00000102 in ?? () #9 0x000000ad in ?? () #10 0x00000000 in ?? () |
|
No.04749
etabeta Developer
Aug 2, 2009, 15:00
|
could someone retest these once 0.133u1 is out? I cannot reproduce anymore these crash on a debug SDLMAME build. All the sets work as expected. Otherwise, the crash is due to some compiler option |
|
No.04750
Tafoid Administrator
Aug 2, 2009, 15:46
|
It doesn't seem to effect SDL .. it's Windows.. it's optimizer related.. and that's about all I know ;) |
|
No.04783
etabeta Developer
Aug 8, 2009, 04:49
|
sorry I had missed your comment 03723 |
|
No.05165
Firewave Senior Tester
Nov 15, 2009, 15:43
|
I just ran the lastest version of cppcheck on the MESS SVN again and look what I got:[c:\svn\mess\src\mame\drivers\videopkr.c:331]: (error) Buffer access out-of-bounds So it might have been a real error after all. A patch for this (and other issues) has already been submitted to MAMEdev. |
|
No.05166
Haze Senior Tester
Nov 15, 2009, 19:03
|
yeah, I don't think there was ever any doubt that this kind of thing was a bug.. but it was impossible to get a decent backtrace of it to work out what the problem was. |
|
No.05167
Tafoid Administrator
Nov 15, 2009, 22:55
|
For what it was worth a week or so ago I was narrowing down which flags caused a crash: -finline-functions -funswitch-loops Doing a -o2 build, along with either or both of those flags caused a crash. Normal -o2 build worked fine here. |
|
No.05170
Haze Senior Tester
Nov 16, 2009, 16:49
|
you were just going off on false leads then. the crash has nothing to do with those switches, it's a simple buffer overrun, corrupting a random byte of memory after the buffer, and causing random crashes depending on exactly what got corrupted (which could change each and every time you recompile and relink) |
|
No.05173
Tafoid Administrator
Nov 16, 2009, 20:33
|
The whole reason I tried to isolate the flag was to give an idea of what the core issue was. The crash happened due to the further optimization than a -o2 build, which might not have been the direct cause - but facilitated the issue into becoming an issue in the first place. |