Oi
Trying to attach a debugger to an application crashing in X11DRV.
Enabled the synchronous trace, and the debugger does start, but it's output doesn't show up on the console. It accepts commands such as c for continue, but it's useless if I want a backtrace, for example. Which I do :-).
Here's the output that it generates: =========================== err:x11drv:error_handler X protocol error: serial=23409562, request_code=53 - breaking into debugger err:ntdll:RtlpWaitForCriticalSection section 0x7f2c5e20 "x11drv_main.c: X11DRV_CritSection" wait timed out in thread 000a, blocked by 0009, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x7f2c5e20 "x11drv_main.c: X11DRV_CritSection" wait timed out in thread 0011, blocked by 0009, retrying (60 sec) ===========================
I had expected that winedbg start printing something after "breaking into debugger" but before "X11DRV_CritSection wait timed out".
I'm going to spend a lot of time fiddling with it now, I'd just like to ask if anyone has a ready explanation (while my story is still short enough to be readable in 5 mins).. Anyone?
If someone can enlighten me, I'd also like to know why a timeout occurs while in the debugger. I had expected debugging to completely suspend the process being debugged?
I had expected that winedbg start printing something after "breaking into debugger" but before "X11DRV_CritSection wait timed out".
I'm going to spend a lot of time fiddling with it now, I'd just like to ask if anyone has a ready explanation (while my story is still short enough to be readable in 5 mins).. Anyone?
If someone can enlighten me, I'd also like to know why a timeout occurs while in the debugger. I had expected debugging to completely suspend the process being debugged?
well, that's strange, the program you stop in the X11 error handler. I tried it here and it works fine. what happens if you try starting the pgm from the debugger ?
Eric Pouech wrote:
well, that's strange, the program you stop in the X11 error handler. I tried it here and it works fine. what happens if you try starting the pgm from the debugger ?
It starts behaving differently compared to running it with plain wine. Still using the synchronous trace, it looks like this:
First chance exception: page fault on read access to 0x7cc7e80a in 32-bit code (0x34032a10). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:34032a10 ESP:7fbcc058 EBP:00000000 EFLAGS:00010297( - 00 RISAP1C) EAX:7cc7e808 EBX:00000660 ECX:00000000 EDX:7cc7e808 ESI:77417078 EDI:00000001 Stack dump: 0x7fbcc058: 00005178 7cccf360 7cccf278 00000000 0x7fbcc068: 00ff00ff ffff009c 00000000 00000000 0x7fbcc078: 00000064 00000000 00000660 0000004b 0x7fbcc088: 00000000 7cc7e808 0000518c 00005180 0x7fbcc098: 0000006c 0000006c 00005190 00000028 0x7fbcc0a8: 00000096 00000064 00200001 00000000 Backtrace: =>1 0x34032a10 in toolkit (+0x32a10) (0x34032a10) 0x34032a10: movb 0x2(%eax),%cl Wine-dbg>
pass'ing the continously rising exceptions about 10 times will allow the application to continue so I can get a backtrace:
err:x11drv:error_handler X protocol error: serial=23186871, request_code=53 - breaking into debugger DebugBreak () at /root/wine-git/dlls/kernel/debugger.c:307 0x7fc17724 DebugBreak+0x4 [/root/wine-git/dlls/kernel/debugger.c:307] in kernel32: popl %ebp 307 } Wine-dbg>0x7fc17724 DebugBreak+0x4 [/root/wine-git/dlls/kernel/debugger.c:307] in kernel32: popl %ebp 307 } Wine-dbg>bt Backtrace: =>1 0x7fc17724 DebugBreak+0x4 [/root/wine-git/dlls/kernel/debugger.c:307] in kernel32 (0x7fc17724) 2 0x7f286cb5 error_handler+0x95(display=0x7c083350, error_evt=0x7fbcc42c) [x11drv_main.c:245] in winex11 (0x7f286cb5) 3 0x7f15f358 _XError+0xda in libx11.so.6 (0x7f15f358) 4 0x7c0516e8 (0x7c0516e8) 5 0x00000000 (0x00000000) 6 0x00000000 (0x00000000) Wine-dbg>
But the backtrace looks corrupted... (or?)
Molle Bestefich wrote:
Eric Pouech wrote:
well, that's strange, the program you stop in the X11 error handler. I tried it here and it works fine. what happens if you try starting the pgm from the debugger ?
It starts behaving differently compared to running it with plain wine. Still using the synchronous trace, it looks like this:
First chance exception: page fault on read access to 0x7cc7e80a in 32-bit code (0x34032a10). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:34032a10 ESP:7fbcc058 EBP:00000000 EFLAGS:00010297( - 00 RISAP1C) EAX:7cc7e808 EBX:00000660 ECX:00000000 EDX:7cc7e808 ESI:77417078 EDI:00000001 Stack dump: 0x7fbcc058: 00005178 7cccf360 7cccf278 00000000 0x7fbcc068: 00ff00ff ffff009c 00000000 00000000 0x7fbcc078: 00000064 00000000 00000660 0000004b 0x7fbcc088: 00000000 7cc7e808 0000518c 00005180 0x7fbcc098: 0000006c 0000006c 00005190 00000028 0x7fbcc0a8: 00000096 00000064 00200001 00000000 Backtrace: =>1 0x34032a10 in toolkit (+0x32a10) (0x34032a10) 0x34032a10: movb 0x2(%eax),%cl Wine-dbg>
pass'ing the continously rising exceptions about 10 times will allow the application to continue so I can get a backtrace:
err:x11drv:error_handler X protocol error: serial=23186871, request_code=53 - breaking into debugger DebugBreak () at /root/wine-git/dlls/kernel/debugger.c:307 0x7fc17724 DebugBreak+0x4 [/root/wine-git/dlls/kernel/debugger.c:307] in kernel32: popl %ebp 307 } Wine-dbg>0x7fc17724 DebugBreak+0x4 [/root/wine-git/dlls/kernel/debugger.c:307] in kernel32: popl %ebp 307 } Wine-dbg>bt Backtrace: =>1 0x7fc17724 DebugBreak+0x4 [/root/wine-git/dlls/kernel/debugger.c:307] in kernel32 (0x7fc17724) 2 0x7f286cb5 error_handler+0x95(display=0x7c083350, error_evt=0x7fbcc42c) [x11drv_main.c:245] in winex11 (0x7f286cb5) 3 0x7f15f358 _XError+0xda in libx11.so.6 (0x7f15f358) 4 0x7c0516e8 (0x7c0516e8) 5 0x00000000 (0x00000000) 6 0x00000000 (0x00000000) Wine-dbg>
But the backtrace looks corrupted... (or?)
or the stack itself :-/ which may explain why winedbg cannot be launch (your first try). A+
-
Eric Pouech -
Molle Bestefich