 No.00060
Tafoid Administrator
Mar 7, 2008, 20:40
|
I tried a self-build debug (with debugger) of 0.123u4 and was unable to get any crashes using -autosave on any of the games you listed. This might be a 64-bit issue, but it doesn't happen for me on 32-bit mainline. Can anyone else duplicate? Are you using fresh save states (made iwth 0.123u4) or ones from a prior version? |
|---|---|
 No.00080
XulChris Tester
Mar 10, 2008, 00:24
|
I tested 0.123u4 sdlmame 64bit on linux using save states and debugger and I was unable to reproduce this. |
 No.00117
aaron Developer
Mar 13, 2008, 21:19
|
No repro here, either. Can you name a specific game and provide a backtrace? |
|
No.00137
Firewave Senior Tester
Mar 14, 2008, 03:59
|
I can reproduce it in 0.123u5. Run this twice: mameud -window -nodebug -autosave eprom And I get this information: ----------------------------------------------------- Exception at EIP=00450A74 (atarimo_render+0x02e6): ACCESS VIOLATION While attempting to read memory at FFFFFFFC ----------------------------------------------------- EAX=FFFFFFFC EBX=00000000 ECX=00000003 EDX=00000000 ESI=F0E9517D EDI=00007C7F EBP=0022FB88 ESP=0022FB30 ----------------------------------------------------- Stack crawl: exception-> 00450A74 (atarimo_render+0x02e6) 0022FB8C: 004619AB (video_update_eprom+0x0055) 0022FBFC: 009CF35F (video_screen_update_partial+0x012d) 0022FC3C: 0044F72F (video_update_atarisy1+0x0a00) 0022FC7C: 00A13608 (timer_set_global_time+0x016e) 0022FCEC: 00A1B925 (cpuexec_timeslice+0x09c3) 0022FE1C: 009C9614 (mame_execute+0x0284) 0022FE7C: 00C00463 (cli_execute+0x01e3) 0022FEEC: 0097950B (utf8_main+0x00ea) 0022FF1C: 01246189 (main+0x00e9) 0022FF6C: 0040124B (__image_base__+0x124b) 0022FFB4: 00401298 (mainCRTStartup+0x0018) and this backtrace: Program received signal SIGSEGV, Segmentation fault. 0x00450a74 in atarimo_render (machine=0xad01f38, map=0, cliprect=0x22fc20, rectlist=0x22fbb4) at src/mame/video/atarimo.c:732 732 mo_render_object(machine, mo, *current, &bandcli p); (gdb) bt full #0 0x00450a74 in atarimo_render (machine=0xad01f38, map=0, cliprect=0x22fc20, rectlist=0x22fbb4) at src/mame/video/atarimo.c:732 current = (struct atarimo_entry **) 0xfffffffc last = (struct atarimo_entry **) 0x22c59fc link = 0 step = -1 first = (struct atarimo_entry **) 0xfffffffc bandclip = {min_x = 0, max_x = 335, min_y = 0, max_y = 7} mo = (struct atarimo_data *) 0x22c2c30 startband = 0 stopband = 7 band = 0 i = 2292768 rect = (rectangle *) 0x1bfd1f80 #1 0x00450a74 in atarimo_render (machine=0xad41f84, map=301342688, cliprect=0x22fc20, rectlist=0xffef) at src/mame/video/atarimo.c:732 current = (struct atarimo_entry **) 0x2 last = (struct atarimo_entry **) 0x74e0 link = 1485053364 step = 4519682 first = (struct atarimo_entry **) 0x26d797e bandclip = {min_x = 0, max_x = 2292728, min_y = 10674857, max_y = 181673860} mo = (struct atarimo_data *) 0x0 startband = 2292728 stopband = 10643956 band = 181673860 i = 10288601 rect = (rectangle *) 0xad41fb0 Backtrace stopped: frame did not save the PC It seems like "current" is messed up after you loaded the savestate. |
|
No.00191
couriersud Developer
Mar 17, 2008, 00:40
|
Save states worked back in 0121. After some analysis, the bug is related to mo->last_link. The logic how this is set and saved has not changed. Therefore we should look at the timing. Back in 0121 mo->last_link must have been reset to -1 after the state got loaded so that mo->activelast != NULL. This does not happen in 0123u5. Is the new implementation of MDRV_CPU_VBLANK_INT behaving like the old did with MDRV_CPU_VBLANK_INT(callback,1)? |