Strange crash

[Dmitry Timoshkov]

"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.