Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 3 Oct 1997 17:54:33 +0200
From:      Martin Cracauer <cracauer@cons.org>
To:        Matthew Thyer <Matthew.Thyer@dsto.defence.gov.au>
Cc:        freebsd-current@FreeBSD.ORG, ports@FreeBSD.ORG
Subject:   Re: xlock: caught signal 8 while running galaxy mode.
Message-ID:  <19971003175433.64822@cons.org>
In-Reply-To: <34348712.F0962930@dsto.defence.gov.au>; from Matthew Thyer on Fri, Oct 03, 1997 at 03:18:02PM %2B0930
References:  <34348712.F0962930@dsto.defence.gov.au>

next in thread | previous in thread | raw e-mail | index | archive | help
In <34348712.F0962930@dsto.defence.gov.au>, Matthew Thyer wrote: 
> Does anyone else have this problem or can anyone confirm that it
> will be solved by a newer incarnation of -CURRENT or a newer
> xlockmore ?
> 
> I run xlockmore-4.02 on a somewhat dated FreeBSD 3.0-CURRENT now
> (3.0-970618-SNAP).
> 
> I always use the galaxy mode for screen locking (because I love it!)
> and it often dies with the following error in my
> .xsession-errors file:
> 
> "xlock: caught signal 8 while running galaxy mode."
> 
> Signal 8 appears to be a floating point exception (FPE) according to
> kill -l.

This has been discusssed several times. FreeBSD defaults to abort a
program at a floating point exception while anyone else does not. The
default for then is to set the result to IEEE exceptional values (InF,
NaN etc.). You can switch all systems to do the other.

I tried to convince people that FreeBSD hurts itself here, and the
dying screensavers are my primary example how this can hurt users. The
solution was to tell the port maintainers to switch FP mode for their
ports, which haven't happend for any port, as far as I know.

There are bugs in our gcc that make relying on FP exceptions handled
right dangerous and Bruce Evans felt it is better to through the
signal, so that people get aware of the problem.

With all respect to Bruce, I'm still conviced that we should switch to
default to set exceptional values and not signal the process. Our gcc
isn't that much worse than NetBSD's and Linux and those systems
obviously didn't get into trouble, at least not my my applications.

I think that a user who maintains a critical floating point program is
much more likely to be aware of turning on exceptions for his program
than any random user is aware of turning them off for a black-box (for
his viewpoint) package like xlockmore.

If you want to change the system-wide default, add this to npx.h
before building a kernel:

undef __INITIAL_NPXCW__
#define __INITIAL_NPXCW__       0x127f

If you come to an educated opinion about the issue a mail to core may
be useful.

Martin
-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer@cons.org> http://www.cons.org/cracauer/
BSD User Group Hamburg/Germany      http://www.bsdhh.org/



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19971003175433.64822>