28 Aug
2004
28 Aug
'04
5:30 p.m.
Hallo,
I am trying to run the WebPACK_42wp30_full_installer.exe
: http://direct.xilinx.com/direct/webpack/42wp3/\
: 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
--
Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
29 Aug
29 Aug
11:24 a.m.
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
7:30 p.m.
>>>> "Mike" == Mike Hearn
<mike(a)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(a)elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
8:21 p.m.
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
--
Softwarepatente: der pure ausgekochte Oberschwachsinn!
20(!!) Jahre Gueltigkeit im schnelllebigen Software-Bereich, jahrelanger
Anmeldungsvorsprung von USA/Japan gegenueber Europa (die machen uns platt),
neuer, radikaler Entwurf des Europarates (selbstverstaendlich ohne Berueck-
sichtigung jeglicher sinnvoller abmildernder Kompromissvorschlaege) unter
Missachtung der direkt gegenlaeufigen Vorentscheidung des Europa-Parlaments,
getrickster Verrat Deutschlands ("wir sind dagegen" -- und wie sie das waren!)
durch unsere werte ganz offensichtlich hochkorrupte BundesInJustizMinisterin
Zypries (welche Gegner der EU-Richtlinie voellig im Regen stehen laesst
und hanebuechene Begruendungen fuer Entscheidungen abgibt).
Fazit: kuenstliche Monopol-Foerderung bei Grosskonzernen mit grossem Patent-
Portfolio (Cross-Licensing), waehrend KMUs in die Roehre schauen (massiver
Ausbau der Rechtsabteilung noetig, da jede einzelne Codezeile gegen ein
Patent verstossen kann). [Sorry, Sig zu lang, aber es ist wirklich noetig...]
30 Aug
30 Aug
12:05 a.m.
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.
31 Aug
31 Aug
8:07 a.m.
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.
7201
days inactive
7204
days old
5 comments
4 participants
participants (4)
-
Andreas Mohr -
Mike Hearn -
Mike Hearn -
Uwe Bonnes