Return to BSD News archive
Path: sserve!manuel!munnari.oz.au!mips!mips!darwin.sura.net!gatech!bloom-beacon!eru.mt.luth.se!lunic!sunic!mcsun!sun4nl!fwi.uva.nl!gene.fwi.uva.nl!vdlinden
From: vdlinden@fwi.uva.nl (Frank van der Linden)
Newsgroups: comp.unix.bsd
Subject: Floating point exception, ps, w, and manpages
Message-ID: <1992Aug11.172957.25340@fwi.uva.nl>
Date: 11 Aug 92 17:29:57 GMT
Sender: news@fwi.uva.nl
Organization: FWI, University of Amsterdam
Lines: 55
Nntp-Posting-Host: gene.fwi.uva.nl
First of all, I'd like to say that I'm very happy to be finally able to
use a complete Unix system that is freely available, including the source
code. Thanks, Bill, Lynne and all the others who contributed.
Now, I've installed 386BSD on my 25 Mhz 386SX + FPU, 8Mb mem and 240Mb disk
a few days ago, and applied a few patches. Amongst them were the patches
to get ps and w to work properly. As many others, I encountered the
'Floating point exception' problem. I started debugging, checked
some values given to both exp() and log(), but did not find any real
problems. Still, I sometimes still got the exception, and in rare cases
(say 4% of the time when using either ps or w), it locked up the system.
I started wondering if the execption was an exception at all, or maybe
the consequence of another bug (although this may seem unlikely). I also
wondered why 'ps' did not dump core a lot of the time when it got the execption
(I was logged in as root, in a writeable directory, why not dump core?).
I tested this little program:
main()
{
log(-1.0);
}
It did NOT get a SIGFPE. So I put a printf() somewhere in npx.c to see
what was wrong. With the printf(), the SIGFPE got through. It seems, that a
little delay in npxintr() is enough to make it work (currently, I've got
a DELAY(5000) in there, it is ugly, and the wrong way to do it, but
at least the signal is sent now). Also, if a user-defined signalhandler
is installed (signal(SIGFPE, xxx)), the signal IS delivered, regardless
of any DELAY() or printf()'s in npx.c. The difference between the two cases,
is that a user-defined signal handler is called through sendsig(), and
SIG_DFL is handled by psignal(). I did not look further into this, but
there is clearly something wrong there.
I am not sure if the occasional system lockup is related to this problem,
but I don't think so, since 'w' locked up my system a few times too.
It's probably in the kvm_xxx stuff, I think (to which I applied patches
posted here, btw). There seems to be another problem in 'ps': why is
the MEM% column always 0.0 ?
Now for something completely different: I did not like standout mode
in yellow on black, so I changed it to black on lightgrey. This made
me notice something in the manpages: sometimes just underscores in
words are in so-mode, and in pathnames, the words are, but the slashes
aren't. This tends to look a bit silly sometimes. Is this a bug
in [ng]roff, or in tmac.andoc, or do I just have a weird taste
when it comes to these things :-)
Frank
--
Frank van der Linden. Internet : vdlinden@fwi.uva.nl
------------------------------------------------------------------------------
'You can't have everything .... where would you put it ?' --- Steven Wright