Strange crash
Dmitry Timoshkov
dmitry at sloboda.ru
Fri Apr 20 03:45:33 CDT 2001
"Rein Klazes" <rklazes at xs4all.nl> wrote:
> > Attached disassembly is almost the same as assember generated by gcc
> > (not counting garbage instead of jump table and fildl (gcc) vs. filds (winedbg))
>
> The 8 instructions or so that I quoted would have been enough. And
> those instructions seem to be assembled OK.
> Btw did you ever check the value that was loaded in the CW, so the 16
> bit value in -2(%edx) ?
Do you mean something like that?
Unhandled exception: c000008f
in 32-bit code (0x40858a6e).
In 32-bit mode.
Symbol h_errno is invalid
Symbol hack_digit is invalid
0x40858a6e (X11DRV_PEN_SelectObject+0x8e [pen.c:69]): fldcw 0xfffffffe(%edx)
69 }
Wine-dbg>info regs
info regs
Register dump:
CS:0023 SS:002b DS:002b ES:002b FS:027f GS:0000
EIP:40858a6e ESP:42005a64 EBP:42005aac EFLAGS:00010202( R- 00 I - - 1 )
EAX:00001640 EBX:4087d00c ECX:4038c7bc EDX:42005a8c
ESI:4038c160 EDI:40807054
Wine-dbg>x ($edx-2)
x ($edx-2)
70001240
Wine-dbg>
I'm sorry, but At&T syntax is not familiar for me. Floating point assembler
instructions either.
> > Also I don't understand why winedbg prints dc->xformWorld2Vport.eM11 = 0.0,
> > though is always 1.0 in the log trace (added to
> > X11DRV_PEN_SelectObject right before the GDI_ROUND call).
> > Something wrong, but I don't know how proceed further yet.
> > Any thoughts?
>
> I would trust the trace, more then the debugger. Things can be really
> tricky though with floating points. The only way to be 100% sure is to
> to show the actual bit pattern. All zero's is 0.0. Anything else is
> not, but a printf can still print 0.0.
Patch from Eric cured the wine debugger.
More information about the wine-devel
mailing list