Re: Strange Crash in Direct X init
On Monday 23 June 2003 00:49, Mike Hearn wrote: > > Can anyone hazard a guess as to what is happening here ? I am at a loss > > to explain why the same call should succeed in one place and fall over in > > another > > NPTL wierdness? I've noticed that if I use an NPTL enabled glibc with a > non-NPTL kernel, all kinds of Wrong Things happen, unexplained thread > crashes, deadlocks etc that disappear when using an NPTL kernel. Apps > that worked before, don't now etc etc. > > I doubt this is your problem as before you said you were using gcc 2.95, > ie not red hat 9, but it might be worth investigating Actually, my Wine is compiled with gcc 3.2,2 and is running under Solaris and used Solaris (IE SysV lwps for threads) . What I am after is just some suggestions because I am out of ideas at the moment. This problem just doesn't make sense.
Re: Strange Crash in Direct X init
> Can anyone hazard a guess as to what is happening here ? I am at a loss to explain > why the > same call should succeed in one place and fall over in another NPTL wierdness? I've noticed that if I use an NPTL enabled glibc with a non-NPTL kernel, all kinds of Wrong Things happen, unexplained thread crashes, deadlocks etc that disappear when using an NPTL kernel. Apps that worked before, don't now etc etc. I doubt this is your problem as before you said you were using gcc 2.95, ie not red hat 9, but it might be worth investigating
Re: Strange crash
On Fri, 20 Apr 2001 14:14:17 +0200, you wrote: > If this is the case a way could be to patch the code to > print the mask with every +relay operation. I think that is a good idea. The function fegetenv(3) can be used for this, the lower 6 bits of member __control_word of the returned structure is the one that we need. Rein -- Rein Klazes [EMAIL PROTECTED]
Re: Strange crash
At 10:30 AM 20/04/2001 +0200, you wrote: >The lower 6 bits are the new floating point exception masks. Mine are >all set and yours are cleared, therefore the crash. > >Why that is the case, I haven't got a clue. I'm not sure I followed everything, but it could come from a problem that occurred a lot of time before, no? The bits could be already cleared on entry of the subroutine. If the exception handling bits are cleared and the app don't do anything with floating point, nothing will break, AFAICT. If this is the case a way could be to patch the code to print the mask with every +relay operation. BTW, I wonder if Dmitry has done some classic tricks like - getting a fresh tree from Winehq - compiling everything with -O0 - trying the same app on another computer with a (as much as possible) different configuration. Gerard
Re: Strange crash
On Fri, 20 Apr 2001 16:45:33 +0800, you wrote: > Wine-dbg>info regs > info regs > Register dump: > CS:0023 SS:002b DS:002b ES:002b FS:027f GS: > EIP:40858a6e ESP:42005a64 EBP:42005aac EFLAGS:00010202( R- 00 I - - 1 ) > EAX:1640 EBX:4087d00c ECX:4038c7bc EDX:42005a8c > ESI:4038c160 EDI:40807054 > Wine-dbg>x ($edx-2) > x ($edx-2) > 70001240 That is what I meant. If I do the same: |Wine-dbg>x $edx-2 | 737f The lower 6 bits are the new floating point exception masks. Mine are all set and yours are cleared, therefore the crash. Why that is the case, I haven't got a clue. Rein. -- Rein Klazes [EMAIL PROTECTED]
Re: Strange crash
"Rein Klazes" <[EMAIL PROTECTED]> 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: c08f 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 0xfffe(%edx) 69 } Wine-dbg>info regs info regs Register dump: CS:0023 SS:002b DS:002b ES:002b FS:027f GS: EIP:40858a6e ESP:42005a64 EBP:42005aac EFLAGS:00010202( R- 00 I - - 1 ) EAX:1640 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.
Re: Strange crash
"eric pouech" <[EMAIL PROTECTED]> wrote: > well, that's a bug in the debugger... > in fact, the debugger passes a float (strictly as a float) to a printf > function, > which expects a double argument, hence the error > this should be a simple fix... let me know if this works better [patch skipped] Yes, now wine debugger prints eM11=1.00 as expected. Thank you.
Re: Strange crash
> Also I don't understand why winedbg prints dc->xformWorld2Vport.eM11 = 0.0,
> though dc->xformWorld2Vport.eM11 is always 1.0 in the log trace (added to
> X11DRV_PEN_SelectObject right before the GDI_ROUND call).
well, that's a bug in the debugger...
in fact, the debugger passes a float (strictly as a float) to a printf
function,
which expects a double argument, hence the error
this should be a simple fix... let me know if this works better
Index: debugger/info.c
===
RCS file: /usr/share/cvs/cvsroot/wine/wine/debugger/info.c,v
retrieving revision 1.17
diff -u -r1.17 info.c
--- debugger/info.c 2000/12/29 05:38:00 1.17
+++ debugger/info.c 2001/04/19 21:19:40
@@ -68,8 +68,18 @@
{
if (strstr(default_format, "%S") == NULL)
{
+ /* float type has to be promoted as a double */
+ /* value.type->un.basic.basic_type == BASIC_FLT */
+ if (strstr(default_format, "%f") != NULL)
+ {
+float f;
+double d;
+memcpy(&f, &res, sizeof(f));
+d = (double)f;
+memcpy(&res, &d, sizeof(res));
+ }
DEBUG_nchar += DEBUG_Printf( DBG_CHN_MESG,
default_format, res );
- }
+ }
else
{
char*
ptr;
--
---
Eric Pouech (http://perso.wanadoo.fr/eric.pouech/)
"The future will be better tomorrow", Vice President Dan Quayle
Re: Strange crash
On Wed, 18 Apr 2001 20:08:12 +0800, you wrote: > "Rein Klazes" <[EMAIL PROTECTED]> wrote: > > [...] > > | fldcw -2(%edx) > > > > Load original CW. Now the exception happens, which indicates the PE > > maskbit is cleared. I don't see how that can be. (you should check > > that the disassembly in winedbg is the same as this code) > > 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) ? > > 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. If you manage to find how this eM11 is stored in memory (in winedbg with something like x &(dc->xformWorld2Vport.eM11) then I can tell you if there is something wrong with it. Rein. -- Rein Klazes [EMAIL PROTECTED]
Re: Strange crash
"Rein Klazes" <[EMAIL PROTECTED]> wrote: [...] > | fldcw -2(%edx) > > Load original CW. Now the exception happens, which indicates the PE > maskbit is cleared. I don't see how that can be. (you should check > that the disassembly in winedbg is the same as this code) Attached disassembly is almost the same as assember generated by gcc (not counting garbage instead of jump table and fildl (gcc) vs. filds (winedbg)) > Moreover I cannot reproduce your failure (using gcc 2.95.4 and gnu as > 2.11.90.0.1) If I set the variables to 0 and 0.0, no exception > follows. I'm completely at loss now. I'm debugging very complex application which actually consists of several simultaneously running processes. Perhaps interaction between processes leads to some unexpected behaviour. Also I don't understand why winedbg prints dc->xformWorld2Vport.eM11 = 0.0, though dc->xformWorld2Vport.eM11 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? Wine-dbg>disas X11DRV_PEN_SelectObject,0x40858b11 disas X11DRV_PEN_SelectObject,0x40858b11 0x40858970 (X11DRV_PEN_SelectObject [pen.c:70]): pushl %ebp 0x40858971 (X11DRV_PEN_SelectObject+0x1 [pen.c:70]): movl %esp,%ebp 0x40858973 (X11DRV_PEN_SelectObject+0x3 [pen.c:70]): subl $60,%esp 0x40858976 (X11DRV_PEN_SelectObject+0x6 [pen.c:70]): pushl %edi 0x40858977 (X11DRV_PEN_SelectObject+0x7 [pen.c:70]): pushl %esi 0x40858978 (X11DRV_PEN_SelectObject+0x8 [pen.c:70]): pushl %ebx 0x40858979 (X11DRV_PEN_SelectObject+0x9 [pen.c:70]): call 0x4085897e (X11DRV_PEN_SelectObject+0xe [pen.c:70]) 0x4085897e (X11DRV_PEN_SelectObject+0xe [pen.c:70]): popl %ebx 0x4085897f (X11DRV_PEN_SelectObject+0xf [pen.c:70]): addl $0x2462e,%ebx 0x40858985 (X11DRV_PEN_SelectObject+0x15 [pen.c:70]): movl 0x8(%ebp),%ecx 0x40858988 (X11DRV_PEN_SelectObject+0x18 [pen.c:70]): movzwl0x52(%ecx),%edx 0x4085898c (X11DRV_PEN_SelectObject+0x1c [pen.c:70]): movl %edx,0xffc4(%ebp) 0x4085898f (X11DRV_PEN_SelectObject+0x1f [pen.c:70]): movl 0x10(%ebp),%edi 0x40858992 (X11DRV_PEN_SelectObject+0x22 [pen.c:70]): movl 0xc(%ebp),%eax 0x40858995 (X11DRV_PEN_SelectObject+0x25 [pen.c:70]): movw %ax,0x52(%ecx) 0x40858999 (X11DRV_PEN_SelectObject+0x29 [pen.c:70]): movl 0x10(%ecx),%esi 0x4085899c (X11DRV_PEN_SelectObject+0x2c [pen.c:70]): movl 0x8(%edi),%eax 0x4085899f (X11DRV_PEN_SelectObject+0x2f [pen.c:70]): andl $15,%eax 0x408589a2 (X11DRV_PEN_SelectObject+0x32 [pen.c:70]): movl %eax,0xc(%esi) 0x408589a5 (X11DRV_PEN_SelectObject+0x35 [pen.c:70]): movl 0x8(%edi),%edx 0x408589a8 (X11DRV_PEN_SelectObject+0x38 [pen.c:70]): andl $0xf,%edx 0x408589ae (X11DRV_PEN_SelectObject+0x3e [pen.c:70]): movl %edx,0x28(%esi) 0x408589b1 (X11DRV_PEN_SelectObject+0x41 [pen.c:70]): movl 0x8(%edi),%eax 0x408589b4 (X11DRV_PEN_SelectObject+0x44 [pen.c:70]): andl $0xf00,%eax 0x408589b9 (X11DRV_PEN_SelectObject+0x49 [pen.c:70]): movl %eax,0x10(%esi) 0x408589bc (X11DRV_PEN_SelectObject+0x4c [pen.c:70]): movl 0x8(%edi),%edx 0x408589bf (X11DRV_PEN_SelectObject+0x4f [pen.c:70]): andl $0xf000,%edx 0x408589c5 (X11DRV_PEN_SelectObject+0x55 [pen.c:70]): movl %edx,0x14(%esi) 0x408589c8 (X11DRV_PEN_SelectObject+0x58 [pen.c:70]): filds 0xc(%edi) 0x408589cb (X11DRV_PEN_SelectObject+0x5b [pen.c:70]): leal 0xffe0(%ebp),%edx 0x408589ce (X11DRV_PEN_SelectObject+0x5e [pen.c:70]): fldl 0x690c(%ebx) 0x408589d4 (X11DRV_PEN_SelectObject+0x64 [pen.c:70]): fxch %st(1) 0x408589d6 (X11DRV_PEN_SelectObject+0x66 [pen.c:70]): fmuls 0xe8(%ecx) 0x408589dc (X11DRV_PEN_SelectObject+0x6c [pen.c:70]): fld %st(1) 0x408589de (X11DRV_PEN_SelectObject+0x6e [pen.c:70]): fmulp %st,%st(1) 0x408589e0 (X11DRV_PEN_SelectObject+0x70 [pen.c:70]): fstps 0xfff8(%ebp) 0x408589e3 (X11DRV_PEN_SelectObject+0x73 [pen.c:70]): flds 0xfff8(%ebp) 0x408589e6 (X11DRV_PEN_SelectObject+0x76 [pen.c:70]): faddp %st,%st(1) 0x408589e8 (X11DRV_PEN_SelectObject+0x78 [pen.c:70]): fnstcw0xfffe(%edx) 0x408589eb (X11DRV_PEN_SelectObject+0x7b [pen.c:70]): movzwl0xfffe(%edx),%eax 0x408589ef (X11DRV_PEN_SelectObject+0x7f [pen.c:70]): andb $0xf3,%ah 0x408589f2 (X11DRV_PEN_SelectObject+0x82 [pen.c:70]): orb $0x4,%ah 0x408589f5 (X11DRV_PEN_SelectObject+0x85 [pen.c:70]): movw %ax,0xfffc(%edx) 0x408589f9 (X11DRV_PEN_SelectObject+0x89 [pen.c:70]): fldcw 0xfffc(%edx) 0x408589fc (X11DRV_PEN_SelectObject+0x8c [pen.c:70]): frndint 0x408589fe (X11DRV_PEN_SelectObject+0x8e [pen.c:70]): fldcw 0xfffe(%edx) 0x40858a01 (X11DRV_PEN_SelectObject+0x91 [pen.c:70]): fstpl 0xffd0(%ebp) 0x40858a04 (X11DRV_PEN_SelectObject+0x94 [pen.c:70]): fldl 0xffd0(%ebp) 0x40858a07 (X11DRV_PEN_SelectObject+0x97 [pen.c:70]): fnstcw0xffce(%ebp) 0x40858a0a (X11DRV_PEN_Se
Re: Strange crash
On Wed, 18 Apr 2001 11:54:37 +0800, you wrote: > I have attached full assembly listing of graphics/x11drv/pen.c produced by gcc. > I removed -g option to reduce the output size and added -S -fverbose-asm. Same as the dissassembly that I see here: | fnstcw -2(%edx) Store the CW in a temporary variable. |#NO_APP | movzwl -2(%edx),%eax | andb $243,%ah | orb $4,%ah This manipulates bits 10 and 11, that control the rounding behaviour. | movw %ax,-4(%edx) |#APP | fldcw -4(%edx) Load the CW with adjusted bits 10 and 11. | frndint Rounding the float value to int, which likely causes a lost precision exception. Because it does not, the PE mask must be set. | fldcw -2(%edx) Load original CW. Now the exception happens, which indicates the PE maskbit is cleared. I don't see how that can be. (you should check that the disassembly in winedbg is the same as this code) Moreover I cannot reproduce your failure (using gcc 2.95.4 and gnu as 2.11.90.0.1) If I set the variables to 0 and 0.0, no exception follows. Rein. -- Rein Klazes [EMAIL PROTECTED]
Re: Strange crash
"Rein Klazes" <[EMAIL PROTECTED]> wrote: > > Exception occurs when pen->logpen.lopnWidth.x = 0 and dc->xformWorld2Vport.eM11 = >0.0 > > It's very strange. Attached patch helps to eliminate crash. But I don't understand > > where the source of problem. > > | 0x40897fde (X11DRV_PEN_SelectObject+0x8e [pen.c:69]): fldcw 0xfffe(%edx) > > This instruction loads the control status word with a new value. Bit 5 > of the CW (0x20) ,PM Precision Mask , is the mask bit for this > exception. > > Find out how this bit has become zero (disassembly of the instructions > before the crash). If I put a breakpoint on the instruction above, the > CW is loaded with 0x37f: all FP exceptions are off. I have attached full assembly listing of graphics/x11drv/pen.c produced by gcc. I removed -g option to reduce the output size and added -S -fverbose-asm. pen.s
Re: Strange crash
On Tue, 17 Apr 2001 12:18:12 +0800, you wrote: > "Alexandre Julliard" <[EMAIL PROTECTED]> wrote: > > > > Commenting lines 36-37 > > > physDev->pen.width = GDI_ROUND((FLOAT)pen->logpen.lopnWidth.x * > > >dc->xformWorld2Vport.eM11 * 0.5); > > > in X11DRV_PEN_SelectObject (graphics/x11drv/pen.c) cures the problem. > > > > > > Why call to floor() leads to crash? > > > > Exception c08f is EXCEPTION_FLT_INEXACT_RESULT. Probably one of > > the floating point values is invalid, or something similar. On the other hand this exception is normally masked, even something as simple as a division of 1.0 by 3.0 can generate it because the result cannot be represented exactly. Also the round-to-int instruction that has just happened here can cause it. So the question would be, why it is not masked? > > Exception occurs when pen->logpen.lopnWidth.x = 0 and dc->xformWorld2Vport.eM11 = 0.0 > It's very strange. Attached patch helps to eliminate crash. But I don't understand > where the source of problem. | 0x40897fde (X11DRV_PEN_SelectObject+0x8e [pen.c:69]): fldcw 0xfffe(%edx) This instruction loads the control status word with a new value. Bit 5 of the CW (0x20) ,PM Precision Mask , is the mask bit for this exception. Find out how this bit has become zero (disassembly of the instructions before the crash). If I put a breakpoint on the instruction above, the CW is loaded with 0x37f: all FP exceptions are off. Rein. -- Rein Klazes [EMAIL PROTECTED]
Re: Strange crash
"Alexandre Julliard" <[EMAIL PROTECTED]> wrote: > > Commenting lines 36-37 > > physDev->pen.width = GDI_ROUND((FLOAT)pen->logpen.lopnWidth.x * > >dc->xformWorld2Vport.eM11 * 0.5); > > in X11DRV_PEN_SelectObject (graphics/x11drv/pen.c) cures the problem. > > > > Why call to floor() leads to crash? > > Exception c08f is EXCEPTION_FLT_INEXACT_RESULT. Probably one of > the floating point values is invalid, or something similar. Exception occurs when pen->logpen.lopnWidth.x = 0 and dc->xformWorld2Vport.eM11 = 0.0 It's very strange. Attached patch helps to eliminate crash. But I don't understand where the source of problem. pen.c.diff
Re: Strange crash
"Dmitry Timoshkov" <[EMAIL PROTECTED]> writes: > Unhandled exception: c08f > [...] > > Commenting lines 36-37 > physDev->pen.width = GDI_ROUND((FLOAT)pen->logpen.lopnWidth.x * >dc->xformWorld2Vport.eM11 * 0.5); > in X11DRV_PEN_SelectObject (graphics/x11drv/pen.c) cures the problem. > > Why call to floor() leads to crash? Exception c08f is EXCEPTION_FLT_INEXACT_RESULT. Probably one of the floating point values is invalid, or something similar. -- Alexandre Julliard [EMAIL PROTECTED]
