| ID | Category [?] | Severity [?] | Reproducibility | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 01092 | Crash/Freeze | Critical (emulator) | Have not tried | Feb 9, 2008, 16:07 | Dec 29, 2008, 23:13 |
| Tester | Firewave | View Status | Public | Platform | |
| Assigned To | robiza | Resolution | Fixed | OS | |
| Status [?] | Resolved | Driver | |||
| Version | 0.123 | Fixed in Version | 0.129 | Build | |
| Fixed in Git Commit | Github Pull Request # | ||||
| Summary | 01092: debugger crashes when exiting during "run to cursor" | ||||
| Description | If you select a line in the debugger and do "Run to cursor" and exit it, it does crash. I reported this in the past, because nobody could reproduce it. I am still having this issue. | ||||
| Steps To Reproduce | |||||
| Additional Information | |||||
| Github Commit | |||||
| Flags | |||||
| Regression Version | |||||
| Affected Sets / Systems | |||||
|
Attached Files
|
 test.diff (928 bytes) Jul 25, 2008, 06:35 | ||||
 No.00193
Firewave Senior Tester
Mar 17, 2008, 00:52
|
I am having a hard time reproducing this issue. It happened to me earlier today under different circumstances, but I can't find the driver anymore. I can reproduce it all the time with "awbios" (I know, a bad example) and it crashes immediately, if you hit F4 and there backtrace looks like this (matches the one I was getting in the first place): ----------------------------------------------------- Exception at EIP=00BF6624 (debug_view_get_property+0x00a3): ACCESS VIOLATION While attempting to read memory at 26F71FE0 ----------------------------------------------------- EAX=26F71FA4 EBX=00000000 ECX=7D947D15 EDX=00000000 ESI=00000001 EDI=0022FB34 EBP=0022F9FC ESP=0022F9E4 ----------------------------------------------------- Stack crawl: exception-> 00BF6624 (debug_view_get_property+0x00a3) 0022FA00: 00983D77 (debugwin_is_debugger_visible+0x1453) 0022FE1C: 009C96B1 (mame_execute+0x0321) 0022FE7C: 00C00463 (cli_execute+0x01e3) 0022FEEC: 0097950B (utf8_main+0x00ea) 0022FF1C: 01246189 (main+0x00e9) 0022FF6C: 0040124B (__image_base__+0x124b) 0022FFB4: 00401298 (mainCRTStartup+0x0018) I try to find a driver without the GAME_NOT_WORKING flag to reproduce it with. |
|---|---|
 No.00199
aaron Developer
Mar 17, 2008, 15:56
|
In order for F4 to have any effect, you have to select a particular instruction. Are you picking anything in particular? Please be very very specific about what actions you are taking. I don't see this crash in awbios. |
|
No.00201
Firewave Senior Tester
Mar 17, 2008, 17:04
|
In the past it was crashing when exiting the debugger no matter what instrcution in what driver you chose. I can reproduce the awbios crash everytime, no matter what instruction I choose. But not inside gdb, so no (x64 crippled) backtrace. I will wait for u6 to try to reproduce it again. |
|
No.01495
Firewave Senior Tester
Jul 5, 2008, 21:14
edited on: Jul 6, 2008, 01:29
|
I can reproduce this with 0.125u9 again. Here is the backtrace (using pacman):
Program received signal SIGSEGV, Segmentation fault.
0x00b7a8bb in debug_view_get_property (view=0x168f1fa4, property=9,
value=0x22fa18) at src/emu/debug/debugvw.c:389
389 value->i = view->supports_cursor;
(gdb) bt full
#0 0x00b7a8bb in debug_view_get_property (view=0x168f1fa4, property=9,
value=0x22fa18) at src/emu/debug/debugvw.c:389
No locals.
#1 0x0091dafc in debug_view_get_property_UINT32 (view=0x168f1fa4, property=9)
at src/emu/debug/debugvw.h:172
value = {i = 4294967295,
s = 0xffffffff <Address 0xffffffff out of bounds>, p = 0xffffffff,
f = 0xffffffff}
#2 0x0091e8a0 in debug_view_proc (wnd=0x8c057c, message=8, wparam=0,
lparam=0) at src/osd/windows/debugwin.c:1428
info = (debugview_info *) 0x1689167c
#3 0x7d9472d8 in USER32!DefDlgProcW () from C:\WINDOWS\syswow64\user32.dll
No symbol table info available.
#4 0x008c057c in draw_sprites (machine=0x91e3fe, bitmap=0x8c057c,
cliprect=0x8) at src/mame/video/welltris.c:105
data3 = 1
y = 660
ytiles = 9176444
xflip = 0
xt = 1
data0 = 2292532
code = 0
xtiles = 8
yflip = 0
data1 = 2106884029
color = 0
xzoom = 2292456
zoomed = 2106880728
data2 = 378082940
x = 0
yzoom = 0
yt = -591746099
offs = 1
visarea = (const rectangle *) 0x0
zoomtable = " |
|
No.01496
Firewave Senior Tester
Jul 6, 2008, 02:09
|
You don't even have to continue the execution. Just select a line and exit the debugger. |
|
No.01501
aaron Developer
Jul 6, 2008, 06:47
|
Again, no repro. You have to specify in exacting detail what you are doing, step by step, or else this bug will never get fixed! What may seem obvious to you is not obvious to someone else trying to reproduce this problem.... |
|
No.01503
Firewave Senior Tester
Jul 6, 2008, 10:05
|
- run MAME with "-window -debug -rp d:\_roms\mame pacman" - select any line in the right part of the debug window - choose "Debug -> Exit" to exit MAME - Access Violation with backtrace as noted above NOTE: MAME was compiled with "SYMBOLS=1 MAP=1 DEBUG=1 UNICODE=1" |
|
No.01516
aaron Developer
Jul 6, 2008, 22:51
|
Must be specific to your configuration. Works fine here, no crashes, same build options.... |
|
No.01517
Firewave Senior Tester
Jul 6, 2008, 22:54
|
I have no configuration. At least no MAME one. I am operating without a mame.ini, so it's all default options. I even made a video of it showing the crash, because this is getting annoying... |
|
No.01519
Firewave Senior Tester
Jul 6, 2008, 23:54
|
Embedding is not working for me. So just the link: |
 No.01537
Stiletto Developer
Jul 8, 2008, 07:20
|
These seem to be 2 different backtraces for 2 different issues, the paths are not the same. As for the second backtrace... if you're debugging pacman, then why does it say this: "src/mame/video/welltris.c" in the log? Finally, I'd say something about syswow64 (could it be a 64-bit issue) but I assume Aaron is running the same. I also assume you're using the official binary from mamedev.org? |
|
No.01546
Firewave Senior Tester
Jul 8, 2008, 17:59
|
I can reproduce it with every official 32-bit binary: D:\mame>mamed -window -debug -rp d:\_roms\mame pacman ----------------------------------------------------- Exception at EIP=00B42767: ACCESS VIOLATION While attempting to read memory at 12B91FE0 ----------------------------------------------------- EAX=12B91FA4 EBX=00000008 ECX=0022FAA4 EDX=00000009 ESI=12B41A7C EDI=00000000 EBP=0022F88C ESP=0022F874 D:\mame>mame -window -debug -rp d:\_roms\mame pacman ----------------------------------------------------- Exception at EIP=00B2B448: ACCESS VIOLATION While attempting to read memory at 00000001 ----------------------------------------------------- EAX=00000000 EBX=055810D0 ECX=0022FA84 EDX=0000000A ESI=0557F9D4 EDI=00000001 EBP=0022F84C ESP=0022EF34 D:\mame>vmame64 -window -debug -rp d:\_roms\mame pacman D:\mame>mamepp -window -debug -rp d:\_roms\mame pacman ----------------------------------------------------- Exception at EIP=00B37DC8: ACCESS VIOLATION While attempting to read memory at 00000001 ----------------------------------------------------- EAX=00000000 EBX=055A10D0 ECX=00000001 EDX=00000013 ESI=00000001 EDI=0000000A EBP=0022F85C ESP=0022EF44 |
|
No.01548
aaron Developer
Jul 8, 2008, 20:20
|
Still no repro, sorry. Seems to be specific to your system. :( |
|
No.01549
amameuser Tester
Jul 8, 2008, 20:23
edited on: Jul 8, 2008, 21:46
|
I can replicate this with the official mame 0.126 debug downloaded from mamedev.org and following Firewave's instructions on Windows XP Service Pack 3 using any driver. - run MAME with "-window -debug pacman" - select any line in the right part of the debug window - choose "Debug -> Exit" to exit MAME - Access Violation ----------------------------------------------------- Exception at EIP=00B42767: ACCESS VIOLATION While attempting to read memory at 19561FE0 ----------------------------------------------------- EAX=19561FA4 EBX=00000008 ECX=0023FAF8 EDX=00000009 ESI=19551A7C EDI=00000000 EBP=0023F8E0 ESP=0023F8C8 Backtrace with DEBUG=1 MAP=1 SYMBOLS=1 Program received signal SIGSEGV, Segmentation fault. 0x00c1cf7b in debug_view_get_property (view=0x1d3d1fa4, property=9, value=0x23fa8c) at src/emu/debug/debugvw.c:389 ??C:\mame0126s/src/emu/debug/debugvw.c:389:13247:beg:0xc1cf7b (gdb) bt #0 0x00c1cf7b in debug_view_get_property (view=0x1d3d1fa4, property=9, value=0x23fa8c) at src/emu/debug/debugvw.c:389 #1 0x00c1cf7b in debug_view_get_property (view=0x1d3d1fa4, property=9, value=0x7e42c228) at src/emu/debug/debugvw.c:389 #2 0x00c1cf7b in debug_view_get_property (view=0x340fc8, property=8, value=0x0) at src/emu/debug/debugvw.c:389 #3 0x00c1cf7b in debug_view_get_property (view=0x9a80dd, property=3411912, value=0x8) at src/emu/debug/debugvw.c:389 #4 0x00c1cf7b in debug_view_get_property (view=0x0, property=10125533, value=0x340fc8) at src/emu/debug/debugvw.c:389 #5 0x00c1cf7b in debug_view_get_property (view=0x6fea350, property=8, value=0x0) at src/emu/debug/debugvw.c:389 #6 0x00c1cf7b in debug_view_get_property (view=0x23fc40, property=24, value=0x6fea350) at src/emu/debug/debugvw.c:389 #7 0x00c1cf7b in debug_view_get_property (view=0x100e72, property=1025, value=0x0) at src/emu/debug/debugvw.c:389 #8 0x00c1cf7b in debug_view_get_property (view=0x9a012e, property=1052274, value=0x401) at src/emu/debug/debugvw.c:389 #9 0x00c1cf7b in debug_view_get_property (view=0x0, property=10092846, value=0x100e72) at src/emu/debug/debugvw.c:389 #10 0x00c1cf7b in debug_view_get_property (view=0xfc4f28, property=117478184, value=0x0) at src/emu/debug/debugvw.c:389 #11 0x00c1cf7b in debug_view_get_property (view=0x100e72, property=1025, value=0x0) at src/emu/debug/debugvw.c:389 #12 0x00c1cf7b in debug_view_get_property (view=0xa641e9c, property=37113024, value=0x23fe28) at src/emu/debug/debugvw.c:389 #13 0x00c1cf7b in debug_view_get_property (view=0x9f41f3c, property=0, value=0x0) at src/emu/debug/debugvw.c:389 #14 0x00c1cf7b in debug_view_get_property (view=0x7221e58, property=119611144, value=0x1befeb0) at src/emu/debug/debugvw.c:389 #15 0x00c1cf7b in debug_view_get_property (view=0x3, property=119218164, value=0x21e56e0) at src/emu/debug/debugvw.c:389 #16 0x00c1cf7b in debug_view_get_property (view=0x3, property=119218164, value=0x3d) at src/emu/debug/debugvw.c:389 #17 0x00c1cf7b in debug_view_get_property (view=0x7ffd8000, property=2, value=0x23ffb0) at src/emu/debug/debugvw.c:389 #18 0x00c1cf7b in debug_view_get_property (view=0x1, property=9, value=0x23fff0) at src/emu/debug/debugvw.c:389 #19 0x00c1cf7b in debug_view_get_property (view=0x0, property=2, value=0x7ffd8000) at src/emu/debug/debugvw.c:389 #20 0x00c1cf7b in debug_view_get_property (view=0x401280, property=0, value=0x78746341) at src/emu/debug/debugvw.c:389 #21 0x00c1cf7b in debug_view_get_property (view=Cannot access memory at address 0x8) at src/emu/debug/debugvw.c:389 Backtrace stopped: previous frame inner to this frame (corrupt stack?) |
 No.01550
Tafoid Administrator
Jul 8, 2008, 20:37
|
This also happens for me (Windows 2000 - Service Pack 4) on 0.126 using MAME -debug pacman (NOTE: -window is automatic once -debug is issued and is not needed). Same thing happens with MAMEDEV Debug build (mamed) with the instructions shown. |
 No.01552
RansAckeR Tester
Jul 8, 2008, 20:57
edited on: Jul 10, 2008, 15:43
|
mame 0.126 (from mamedev) on P4 2.4, 1GB, XP Pro SP3 32bit: C:\emu\mame>MAME -debug pacman ----------------------------------------------------- Exception at EIP=00B2B448: ACCESS VIOLATION While attempting to read memory at 00000001 ----------------------------------------------------- EAX=00000000 EBX=034B8D20 ECX=0022FAD8 EDX=0000000A ESI=0360930C EDI=00000001 EBP=0022F8A0 ESP=0022EF88 debugvw.c line 389: value->i = view->supports_cursor: "Unhandled exception at 0x00d6920a in vmamed.exe: 0xC0000005: Access violation reading location 0x194d1fe0." vmamed.exe!debug_view_get_property(_debug_view * view=0x194d1fa4, int property=9, _debug_property_info * value=0x0012fb2c) Line 389 + 0x6 bytes vmamed.exe!debug_view_get_property_UINT32(_debug_view * view=0x194d1fa4, int property=9) Line 172 + 0x11 bytes vmamed.exe!debug_view_proc(HWND__ * wnd=0x001204ee, unsigned int message=8, unsigned int wparam=0, long lparam=0) Line 1428 + 0xe bytes user32.dll!_InternalCallWinProc@20() + 0x28 bytes user32.dll!_UserCallWinProcCheckWow@32() + 0xb7 bytes user32.dll!_DispatchClientMessage@20() + 0x4d bytes user32.dll!___fnDWORD@4() + 0x24 bytes ntdll.dll!_KiUserCallbackDispatcher@12() + 0x13 bytes user32.dll!_NtUserDestroyWindow@4() + 0xc bytes user32.dll!_InternalCallWinProc@20() + 0x28 bytes user32.dll!_UserCallWinProcCheckWow@32() + 0xb7 bytes user32.dll!_SendMessageWorker@20() + 0xc8 bytes user32.dll!_SendMessageA@16() + 0x49 bytes vmamed.exe!winwindow_video_window_destroy(_win_window_info * window=0x07011e9c) Line 683 vmamed.exe!winwindow_exit(_running_machine * machine=0x06961f3c) Line 276 + 0x9 bytes vmamed.exe!mame_execute(_core_options * options=0x03c41e58) Line 421 + 0xc bytes vmamed.exe!cli_execute(int argc=4, char * * argv=0x03bc1ff0, const _options_entry * osd_options=0x01f01c90) Line 171 + 0x9 bytes vmamed.exe!utf8_main(int argc=4, char * * argv=0x03bc1ff0) Line 257 + 0x12 bytes vmamed.exe!main(int argc=4, char * * argv=0x03ba32d0) Line 72 + 0xd bytes vmamed.exe!__tmainCRTStartup() Line 266 + 0x19 bytes vmamed.exe!mainCRTStartup() Line 182 kernel32.dll!_BaseProcessStart@4() + 0x23 bytes Note: After I click exit, if I don't move my mouse, the window seems frozen. The millisecond I touch my mouse it crashes. Is this normal behaviour? |
|
No.01564
RansAckeR Tester
Jul 9, 2008, 21:38
|
In debugwin.c, shouldn't it test if info->view->supports_cursor is not null before getting the property? All info->view properties seem to have a NULL value in this case. case WM_KILLFOCUS: { if (debug_view_get_property_UINT32(info->view, DVP_SUPPORTS_CURSOR)) debug_view_set_property_UINT32(info->view, DVP_CURSOR_VISIBLE, 0); break; } |
|
No.01784
aaron Developer
Jul 25, 2008, 06:35
|
Still no repro here. Try the attached patch (test.diff) to see if it makes any difference. |
|
No.01812
amameuser Tester
Jul 26, 2008, 16:20
|
Sorry, the patch didn't seem to make any difference here. Tested against MAME 0.126u2. |
|
No.01828
Firewave Senior Tester
Jul 27, 2008, 20:20
|
I did a trace of the windows message to find an issue there. When the crash happens, that has been no WM_NCDESTROY yet, so the view should still be valid (I assume the view object is bad). Seems something else is messing it up. |
|
No.01841
Firewave Senior Tester
Jul 29, 2008, 22:30
|
Yout hunch with the debugwin_destroy_windows() was right, but it isn't fixed yet. For some reason the debug_view_exit() call happens before the debugwin_destroy_windows() so the free'd debug_view objects are still being accessed. At least with your patch debugwin_destroy_windows() is called at all in my case. Here is the final lines of my trace: debug_view_proc - 512 debug_view_exit() debug_view_free() - 16441FA4 debug_view_free() - 16411FA4 debug_view_free() - 163B1FA4 debugwin_destroy_windows() debug_window_proc - 70 debug_window_proc - 71 debug_window_proc - 134 debug_window_proc - 6 debug_window_proc - 70 debug_view_proc - 8 debug_view_get_property() - 163B1FA4 9 - begin |
|
No.01842
Firewave Senior Tester
Jul 29, 2008, 22:55
|
I think I now understand it and know what the problem is. As the window access the debug views they have to create when the debug views already exist and destroyed while they still exist. At the moment the debug views are created after the windows. I am not sure, if this is even possible, but I will try tomorrow. Could be a chicken/egg problem. |
|
No.03422
Firewave Senior Tester
Dec 28, 2008, 23:07
|
I am having this (or a similar problem) in 0.128u7. It now crashes with the usage of an NULL pointer after I just selected a line in the debugger and exit it.
Program received signal SIGSEGV, Segmentation fault.
0x00bc5ce2 in debug_view_begin_update (view=0x0)
at src/emu/debug/debugvw.c:475
475 view->update_level++;
(gdb) bt full
#0 0x00bc5ce2 in debug_view_begin_update (view=0x0)
at src/emu/debug/debugvw.c:475
No locals.
#1 0x00bc6085 in debug_view_get_cursor_supported (view=0x0)
at src/emu/debug/debugvw.c:730
No locals.
#2 0x0096c80d in debugwin_view_proc (wnd=0x3ef04ae, message=8,
wparam=236388562, lparam=0) at src/osd/windows/debugwin.c:1388
info = (debugview_info *) 0x16bd1688
#3 0x7d9472d8 in USER32!DefDlgProcW () from C:\WINDOWS\syswow64\user32.dll
No symbol table info available.
#4 0x03ef04ae in ?? ()
No symbol table info available.
#5 0x00000008 in ?? ()
No symbol table info available.
#6 0x0e1700d2 in ?? ()
No symbol table info available.
#7 0x00000000 in ?? ()
No symbol table info available.
|
|
No.03426
robiza Developer
Dec 29, 2008, 12:03
edited on: Dec 29, 2008, 12:08
|
same bug in my personal build C:\svn\trunk>mame -debug pacman ---------------------------------------------------- Exception at EIP=00B6307A: ACCESS VIOLATION While attempting to read memory at 0000004F ---------------------------------------------------- EAX=00000000 EBX=00000000 ECX=76C69411 EDX=00000000 ESI=093417DC EDI=0022F9AC EBP=0022F710 ESP=0022F6F8 there's a strange issue when i have select exit from the menu (only one click and don't move the mouse), mame wait for something in a infinite loop when i move the mouse mame exit and show the error probably it's necessary remove the selection before the exit (if i press esc and remove the selection, all things are ok) |
|
No.03427
robiza Developer
Dec 29, 2008, 12:23
|
this code fix the bug in debugwin.c in static int global_handle_command(debugwin_info *info, WPARAM wparam, LPARAM lparam) function: forcing the focus case ID_EXIT: if (info->focuswnd != NULL) SetFocus(info->focuswnd); mame_schedule_exit(info->machine); return 1; |
|
No.03428
Firewave Senior Tester
Dec 29, 2008, 14:24
|
Yes! That fixed it for me. I am also not getting any other crashes related to selected lines in the debugger. If this fix will be accepted, the bug can be closed. |