*BSD News Article 3497


Return to BSD News archive

Xref: sserve comp.unix.bsd:3541 comp.bugs.4bsd:1886
Path: sserve!manuel!munnari.oz.au!hp9000.csc.cuhk.hk!uakari.primate.wisc.edu!sdd.hp.com!wupost!uunet!iWarp.intel.com|ichips!intelhf!agora!davidg
From: davidg@agora.rain.com (David Greenman)
Newsgroups: comp.unix.bsd,comp.bugs.4bsd
Subject: 'ps aux' floating exception bug (386BSD)
Message-ID: <1992Aug7.125733.16779@agora.uucp>
Date: 7 Aug 92 12:57:33 GMT
Sender: davidg@agora.uucp (David Greenman)
Organization: Open Communications Forum
Lines: 46


   After a suggestion from Arne Henrik Juul <arnej@lise.unit.no>, I
decided to replace the stock libm.a with the 386 assembly version
that I ported from mach back when I was using 0.0. The problem with
'ps aux' "Floating Point Exception" is now gone.
   I still don't know why the exception is reported so late when
using gdb, nor do I understand why the problem was intermittent. I
suspect that there is a bug somewhere in the kernel with the handling
of the FPU.
   I ran 'paranoia' with the supplied libm.a; here is what it
uncovered:

....
Testing powers Z^i for small Integers Z and i.
DEFECT:  computing
        (2.00000000000000000e+00) ^ (3.00000000000000000e+00)
        yielded 7.99999999999281997e+00;
        which compared unequal to correct 8.00000000000000000e+00 ;
                they differ by -7.18003434485581238e-12 .
Errors like this may invalidate financial calculations
        involving interest rates.
Similar discrepancies have occurred 121 times.

....

Testing X^((X + 1) / (X - 1)) vs. exp(2) = 7.38905609893065218e+00 as X -> 1.
Accuracy seems adequate.
Testing powers Z^Q at four nearly extreme values.
DEFECT:  computing
        (2.00000000000000000e+00) ^ (1.00700000000000000e+03)
        yielded 1.37153101719718930e+303;
        which compared unequal to correct 1.37153101719842530e+303 ;
                they differ by -1.23095497606496200e+291 .
Similar discrepancies have occurred 4 times.

....
These problems don't occur when 'paranoia' is linked with the assembly
version of libm.a. While these two 'DEFECT's seem somewhat minor, they
may very well be indicative of a more serious problem.
I recall that someone else did a port of the GNU 386 libm.a a while
back...is this conveniently available somewhere, or would it be
prudent for me to make my port of this available?

---
David Greenman
davidg%implode@agora.rain.com