Return to BSD News archive
Newsgroups: comp.os.386bsd.bugs Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!convex!convex!cs.utexas.edu!usc!howland.reston.ans.net!agate!netsys!bugs From: bugs@NETSYS.COM (Mark Hittinger) Subject: Re: Floating exceptions? Message-ID: <bugs.732944661@netsys.com> Sender: news@netsys.com Organization: Netsys Inc. References: <f0XUP76@quack.kfu.com> Date: Wed, 24 Mar 1993 03:44:21 GMT Lines: 32 mrapple@quack.kfu.com (Nick Sayer) writes: >0.2.2 running on a 486-50 with 16M RAM. I compiled xv_calctool >(patchlevel 12). If I try and find ln(10000)/ln(10), it crashes with >a floating point exception. The same code on a sun does not. >If I try and get a stack-trace on the resulting core, it >crashes in routines that haven't the slightest thing to do with >floating point. >Has anyone seen this behavior before? Might there be some delay between >the occurance of the problem and the exception or something? Yes - operations on certain "illegal" real numbers cause the floating point coprocessor to blow up the stack. Other hardware designs are a little better about handling exceptions. Another problem that comes up with compiler optimization is that the x86 floating point processor has a fixed size stack. I see bad object code that leaves things on the stack and forgets about it. Then a program attempts to put something on the stack and an exception is generated. We've had to write a number of routines that process real numbers and test for these "illegal" reals before operating on them. These "illegal" reals come out of garbage data files or from poorly written code (uninitialized variables). Good luck. --------- whats back with the wrong-ups?