[comp.windows.x] SIGFPE in miFillSppPoly

rob@cetia.UUCP (06/21/89)

Occasionally we get Not-a-Number floating point exceptions in ceil()
called from miFillSppPoly().

The system we are running under is derived from Motorola system V.2
but with NFS, sockets, and other BSD goodies.

i checked out how ceil() performs on a sun and on another BSD system
and it returns something sensible when passed a NaN as parameter
(MAXINT or -MAXINT depending on whether what wasn't a number was positive
or negative).

However, with the motorola maths libraries ceil(), in this situation,
generates a SIGFPE.

i have looked at the code, briefly, for miFillSppPoly()
and it does seem possible that the variables xl and xr could be passed
to ceil() without having been initialized.
The algorithm might actually preclude this but i haven't examined it that
closely.

>From what i've seen of the differences between sysV and BSD maths libraries
an unitialized variable, when passed to ceil(),
wouldn't do any harm under BSD and so might not be noticed.

by the way the value that ceil() blew up on was
	(double)0x7fffFFFFffffFFFF

thanks in advance for any help
rob

ps
if this is the result of some sort of overflow condition rather
than unitialized data then i'll have to bring the maths libraries
on our systems up to spec with BSD

rob@cetia.UUCP (Rob Gordon) (06/22/89)

i'm posting this on the news because the mail i sent to xpert
has bounced several times, so i'm not sure if it got through.

the mail concerned what appears to be a problem of unitialized variables
in miFillSppPoly() (server/ddx/mi/mifpolycon.c).

the problem arises on our system because the Green Hills cc is pretty clever
about making use of the FPU, but if an FPU register has not been initialized 
previously then it contains a Not-a-Number value.
Subsequent use of this value (ie using the unitialized variable that is held
in the FPU register) results in a SIGFPU in ceil().

there are paths through miFillSppPoly() which could mean
(unless precluded by the algorithm, but i haven't checked this)
that the double variables ml, mr, xl, and xr can be used without
being initialized, which is what appears to be catching me.

i've added a line at the top of the function to initialize all four to 0.0,
which i hope is a reasonable value.

i'm pretty certain this is a systemV specific bug, because the BSD maths
library does something sensible with NaN values whereas the sysV libraries
generate SIGFPE.

cheers
rob
-- 
Rob Gordon
				rob@inset.co.uk
				...!mcvax!ukc!inset!rob

doyle@b11.ingr.com (Doyle Davidson) (06/23/89)

In article <8906211551.AA07986@inria.inria.fr>, rob@cetia.UUCP writes:
> Occasionally we get Not-a-Number floating point exceptions in ceil()
> called from miFillSppPoly().
...
> i have looked at the code, briefly, for miFillSppPoly()
> and it does seem possible that the variables xl and xr could be passed
> to ceil() without having been initialized.
> The algorithm might actually preclude this but i haven't examined it that
> closely.
> 
From looking at the code myself (which am and trying not to use since
we are having problems with truly meeting the X spec and I think this
is the culprit)  The only way that I can see xl and xr not being initialized
is if the points passed in (which have to be 3 or more) are all linear
(and may actually have to be horizontal too i.e. dy=0)
which seems rather difficult since it is called from:
    miWideLine - a line always has width so won't be linear points
	(0 width will be treated as width 1 if it makes it here)
    miarc.c    - can't say for sure about this one
    miWideDash - can see any way here since dashes once again have width
    (did I miss any folks?)

So my real question is what are you doing that is causing this weird value?

Doyle (mi code is slow, and it doesn't work too) Davidson
------------------------------------------------------------------
Doyle C. Davidson              |
Intergraph Corp.               |  These comments are...
Workstation Graphics Standards |
1 Madison Industrial Park      |     \\  /
Huntsville, AL 35806           |      \\/
(205) 772-2000                 |      /\\  clusively my own.
                               |     /  \\
..!uunet!ingr!b11!doyled!doyle |
------------------------------------------------------------------