Hallo,
I am trying to run the WebPACK_42wp30_full_installer.exe : http://direct.xilinx.com/direct/webpack/42wp3/%5C : WebPACK_42wp30_full_installer.exe (a 110 MByte Download).
Running it crashes quite early, while testing the debug channels: err:font:ReadFontDir Can't open directory "/usr/X11R6/lib/X11/fonts/TrueType" err:font:ReadFontDir Can't open directory "/usr/X11R6/lib/X11/fonts/TT" wine: Unhandled exception (thread 0009), starting debugger... fixme:console:SetConsoleCtrlHandler (0x405ac2f0,1) - no error checking or testing yet WineDbg starting on pid 0x8 Unhandled exception: page fault on read access to 0xc0685566 in 32-bit code (0x40710c60). In 32 bit mode. 0x40710c60 WINPROC_CallWndProc [/home/wine/wine/dlls/user/../../windows/winproc.c:232] in user32: testb $0x8,0x0(%eax) 232 if (TRACE_ON(relay)) 232 if (TRACE_ON(relay)) Wine-dbg>Backtrace: =>1 0x40710c60 WINPROC_CallWndProc+0x70(wParam=0x1002c, lParam=0x0) [/home/wine/wine/dlls/user/../../windows/winproc.c:232] in user32 (0x4067fb7c) 2 0x4071578d CallWindowProcA+0xed(func=0x4078656c, hwnd=0x10022, msg=0x110, wParam=0x1002c, lParam=0x0) [/home/wine/wine/dlls/user/../../windows/winproc.c:3123] in user32 (0x4067fba0) 3 0x406eb083 DefDlgProcA+0x63(hwnd=0x10022, msg=0x110, wParam=0x1002c, lParam=0x0) [/home/wine/wine/dlls/user/../../windows/defdlg.c:451] in user32 (0x4067fbd0) 4 0x40710437 WINPROC_wrapper+0x17 in user32 (0x4067fbf4) 5 0x40710c4c WINPROC_CallWndProc+0x5c(wParam=0x1002c, lParam=0x0) [/home/wine/wine/dlls/user/../../windows/winproc.c:230] in user32 (0x4067fc30) 6 0x4071578d CallWindowProcA+0xed(func=0x406eb020, hwnd=0x10022, msg=0x110, wParam=0x1002c, lParam=0x0) [/home/wine/wine/dlls/user/../../windows/winproc.c:3123] in user32 (0x4067fc54) 7 0x40725b8f call_window_proc+0x11f(lparam=0x0, unicode=0x0, same_thread=0x1) [/home/wine/wine/dlls/user/message.c:1461] in user32 (0x4067fcb8) 8 0x4072839e SendMessageTimeoutA+0x1be(hwnd=0x10022, msg=0x110, wparam=0x1002c, lparam=0x0, flags=0x0, timeout=0xffffffff, res_ptr=0x4067fd3c) [/home/wine/wine/dlls/user/message.c:1968] in user32 (0x4067fd18) 9 0x40728425 SendMessageA+0x35(hwnd=0x10022, msg=0x110, wparam=0x1002c, lparam=0x0) [/home/wine/wine/dlls/user/message.c:2012] in user32 (0x4067fd44) 10 0x406efc5c DIALOG_CreateIndirect+0x107c(dlgProc=0x4012df, param=0x0, unicode=0x0, modal=0x1) [/home/wine/wine/dlls/user/../../windows/dialog.c:672] in user32 (0x4067fe54) 11 0x406f04be DialogBoxParamA+0x4e(hInst=0x400000, name=0x12c, owner=0x0, dlgProc=0x4012df, param=0x0) [/home/wine/wine/dlls/user/../../windows/dialog.c:821] in user32 (0x4067fe78) 12 0x0040184d (0x004137a2)
It seems the location of the debug channels is picked up from the ebx register Wine-dbg>disass 0x40710c52 0x40710c52 WINPROC_CallWndProc [../windows/winproc.c:231] in user32: call 0x40707c70 WIN_RestoreWndsLock [/home/wine/wine/dlls/user/../../windows/user.c:183] in user32 0x40710c57 WINPROC_CallWndProc [../windows/winproc.c:232] in user32: movl 0x190(%ebx),%eax 0x40710c5d WINPROC_CallWndProc [../windows/winproc.c:232] in user32: addl $24,%esp 0x40710c60 WINPROC_CallWndProc [../windows/winproc.c:232] in user32: testb $0x8,0x0(%eax)
I wonder what can trash the testing of the debug channels. I ran with +heap to look for heap corruption, but couldn't find something.
Uncommenting the offending code
if (TRACE_ON(relay)) DPRINTF( "%04lx:Ret window proc %p (hwnd=%p,msg=%s,wp=%08x,lp=%08lx) retval=%08lx\n", GetCurrentThreadId(), proc, hwnd, SPY_GetMsgName(msg, hwnd), wParam, lParam, retvalue );
makes the application proceed.
Bye
On Sat, 28 Aug 2004 19:30:58 +0200, Uwe Bonnes wrote:
It seems the location of the debug channels is picked up from the ebx register
%ebx is supposed to point to the ELF global offset table, iirc. If it's been reset somewhere then it could cause this sort of crash when accessing global vars in an external library as I imagine debug channels are.
The offending line is printing the *return* value of the function so I really suspect this is similar to a problem reported earlier this year (?) where some win32 code wasn't performing register saves correctly. I bet this is the same problem.
I wonder what can trash the testing of the debug channels. I ran with +heap to look for heap corruption, but couldn't find something.
Try wrapping the window proc callout with some code that saves %ebx on the stack. There is an example in another part of the code but I can't remember what! :(
If you compile the relevant DLL with optimization off you may be able to get away with this for testing the theory:
__asm__("push %ebx") // make the call to the wndproc here __asm__("pop %ebx") // now test the debug channel and carry on
The reason it works if you comment out the debug channel code is that %ebx is reset by gcc generated code on entry to an ELF exported function.
thanks -mike
"Mike" == Mike Hearn mike@navi.cx writes:
Mike> On Sat, 28 Aug 2004 19:30:58 +0200, Uwe Bonnes wrote: >> It seems the location of the debug channels is picked up from the ebx >> register
Mike> %ebx is supposed to point to the ELF global offset table, iirc. If Mike> it's been reset somewhere then it could cause this sort of crash Mike> when accessing global vars in an external library as I imagine Mike> debug channels are.
Mike> The offending line is printing the *return* value of the function Mike> so I really suspect this is similar to a problem reported earlier Mike> this year (?) where some win32 code wasn't performing register Mike> saves correctly. I bet this is the same problem.
>> I wonder what can trash the testing of the debug channels. I ran with >> +heap to look for heap corruption, but couldn't find something.
Mike> Try wrapping the window proc callout with some code that saves Mike> %ebx on the stack. There is an example in another part of the code Mike> but I can't remember what! :(
Mike> If you compile the relevant DLL with optimization off you may be Mike> able to get away with this for testing the theory:
Mike> __asm__("push %ebx") // make the call to the wndproc here Mike> __asm__("pop %ebx") // now test the debug channel and carry on
Mike> The reason it works if you comment out the debug channel code is Mike> that %ebx is reset by gcc generated code on entry to an ELF Mike> exported function.
With -O2: fixme:dbghelp:elf_lookup_symtab Already found symbol add_paint_count (/spare/wine/wine/dlls/user/../../windows/painting.c) in symtab painting.c @0007c970 and painting.c @000abd40 0x40740f48 WINPROC_CallWndProc [/spare/wine/wine/dlls/user/../../windows/winproc.c:231] in user32: testb $0x8,0x0(%eax) 231 if (TRACE_ON(relay)) 231 if (TRACE_ON(relay))
With -O2 removed from dlls/user/Makefile and winproc.c recompiled WineDbg starting on pid 0x8 Unhandled exception: page fault on read access to 0x59535445 in 32-bit code (0x40740f9f). In 32 bit mode. fixme:dbghelp:elf_lookup_symtab Already found symbol add_paint_count (/spare/wine/wine/dlls/user/../../windows/painting.c) in symtab painting.c @0007c970 and painting.c @000acd90 0x40740f9f WINPROC_CallWndProc [../../windows/winproc.c:231] in user32: movsbl 0x0(%eax),%eax Unable to open file ../../windows/winproc.c
With -O2 removed from dlls/user/Makefile, retvalue = WINPROC_wrapper( proc, hwnd, msg, wParam, lParam ) surrounded with __asm__("push %ebx") and __asm__("pop %ebx") the installer doesn't crash at that place.
However I wonder: __ASM_GLOBAL_FUNC( WINPROC_wrapper, ...
has also "pushl %ebx\n\t" and "popl %ebx\n\t" surrounding "call *%eax\n\t"
Why does this double restoring ebx help?
Bye
Hi,
On Sun, Aug 29, 2004 at 09:30:50PM +0200, Uwe Bonnes wrote:
Unhandled exception: page fault on read access to 0x59535445 in 32-bit code
SYSTEM? ("YSTE")
Andreas Mohr
On Sun, 29 Aug 2004 21:30:50 +0200, Uwe Bonnes wrote:
Why does this double restoring ebx help?
Good question. I don't know.
Possibly the window procedure is declared using a calling convention that somehow mangles even the wrapper stack, so we're popping garbage off it into %ebx. But I'm out of ideas for now.
Good question. I don't know.
Possibly the window procedure is declared using a calling convention that somehow mangles even the wrapper stack, so we're popping garbage off it into %ebx. But I'm out of ideas for now.
What I would suggest is putting some stack padding between the saved registers and the window proc parameters. If that makes a difference submit it to wine-patches, as it's likely that the padding has been blasted rather than the register save area.
-
Andreas Mohr -
Mike Hearn -
Mike Hearn -
Uwe Bonnes