From:	<ams AT ludd DOT luth DOT se>
Message-Id:	<200305241240.h4OCe1Db002721@speedy.ludd.luth.se>
Subject:	printf crash in t-strtof (was: Re: Yet another try on nan in strto{f,d,ld})
In-Reply-To:	<3405-Tue06May2003193807+0300-eliz@elta.co.il> "from Eli Zaretskii
	at May 6, 2003 07:38:08 pm"
To:	djgpp-workers AT delorie DOT com
Date:	Sat, 24 May 2003 14:40:01 +0200 (CEST)
X-Mailer:	ELM [version 2.4ME+ PL78 (25)]
MIME-Version:	1.0
X-MailScanner:	Found to be clean
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

According to Eli Zaretskii:
> > From: <ams AT ludd DOT luth DOT se>
> > Date: Mon, 5 May 2003 21:48:01 +0200 (CEST)
> > 
> > A:\>ts3
> > FPU CW: 0x00000340.
> > float tests:
> > Exiting due to signal SIGFPE
> > Floating Point exception at eip=00005e21, x87 status=b1a0
> > eax=000917ac ebx=00092c2b ecx=0000000c edx=00090f40 esi=000918ad edi=00000006
> > ebp=0009171c esp=00091718 program=A:\TS3.EXE
> > cs: sel=00bf  base=00116000  limit=0009ffff
> > ds: sel=00c7  base=00116000  limit=0009ffff
> > es: sel=00c7  base=00116000  limit=0009ffff
> > fs: sel=009f  base=000051d0  limit=0000ffff
> > gs: sel=00d7  base=00000000  limit=0010ffff
> > ss: sel=00c7  base=00116000  limit=0009ffff
> > App stack: [00092dc4..00012dc4]  Exceptn stack: [00012d44..00010e04]
> >  
> > Call frame traceback EIPs:
> >   0x00005e21 __modfl+33, file a:/doprnt.c, line 924
> > Line 592 is "tmp = modfl(integer * 0.1L , &integer);".
> > 
> > Worth to note is that the previous modfl() at line 575 worked fine.
> > 
> > And this is an "objdump -d" of the relevant instructions in modfl:
> > 
> > 00005e00 <___modfl>:
> >     5e00:       55                      push   %ebp
> >     5e01:       89 e5                   mov    %esp,%ebp
> >     5e03:       83 ec 04                sub    $0x4,%esp
> >     5e06:       db 6d 08                fldt   0x8(%ebp)
> >     5e09:       8b 45 14                mov    0x14(%ebp),%eax
> >     5e0c:       d9 7d fe                fnstcw 0xfffffffe(%ebp)
> >     5e0f:       66 8b 55 fe             mov    0xfffffffe(%ebp),%dx
> >     5e13:       80 ce 0c                or     $0xc,%dh
> >     5e16:       66 89 55 fc             mov    %dx,0xfffffffc(%ebp)
> >     5e1a:       d9 6d fc                fldcw  0xfffffffc(%ebp)
> >     5e1d:       d9 c0                   fld    %st(0)
> >     5e1f:       d9 fc                   frndint 
> >     5e21:       d9 6d fe                fldcw  0xfffffffe(%ebp)
> 
> AFAIU, the last line above is the one that crashed.  What is the
> operand(s) of the FLDCW instruction that crashed, and what is at
> 0xfffffffe(%ebp) on the stack?
> 
> Also, it could be that the actual exception was somewhere else, if
> FLDCW is one of the instructions that does the equivalent of FWAIT.
> (Or am I confused?)  So it might be a good idea to step with GDB thru
> this code and examine the FPU status word after each instruction.
> When one of the exception bits in the status word gets set, that's
> when the exception actually happens.

I can't. Or rather it's too painful/timeconsuming. When I run this in
gdb in plain DOS, it hangs the computer. Presumably it's when a SIGFPE
appears. And when I say hang, it means it's time for the reset button.

gdb --version says 5.3.


Right,

						MartinS

- Raw text -