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