Debug Channels trashed
Uwe Bonnes
bon at elektron.ikp.physik.tu-darmstadt.de
Sun Aug 29 14:30:50 CDT 2004
>>>>> "Mike" == Mike Hearn <mike at 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
--
Uwe Bonnes bon at elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
More information about the wine-devel
mailing list