lotto@wjh12.UUCP (Jerry Lotto) (11/21/86)
A recent posting in net.sources (gnuplot), compiled with Microsofts C compiler v 4.0 causes my machine to hang up. Only a hard reset brings it back. I traced the problem to a single machine instruction! The problem arises in the _log10 routine. In the debugger(s), I was able to trace the problem down to the following. There are three items on the stack, and we hit an FLD ST(0). This is supposed to duplicate the top item on the stack. On my machine, it operates similarly to a HALT. The 80287 appears to be well before the instruction. Stepping to it, manually setting up the 80287, etc. all give the same results. Other 80287 instructions work just fine. I have yet to try this on another box. I assume everything will work out OK. Does anyone know what could be going on here? Thanks in advance for any light that can be shed on this problem.
lotto@wjh12.UUCP (Jerry Lotto) (11/22/86)
I found the problem. For ref, the stack was full. The behavior was less than graceful, but when another value was pushed - ZAP! The garbage on the stack accumulated from assorted divide by zero exceptions that were not being cleaned up after. Debugging this was not fun. There were lots of twisty passages, all alike. At any rate, the solution is a call to _fpreset in the floating point exception code (fpe() in parse.c). I put mine inside an #ifdef MSC.
lotto@wjh12.UUCP (Jerry Lotto) (11/22/86)
The problem was a full 80287 stack. The FPE from previous divide by zero stuff was not cleaning up after itself, and after 5 such problems, the stack over- flowed. I posted a fix to net.sources.d.
lotto@wjh12.UUCP (Jerry Lotto) (11/22/86)
The fix for gnuplot is to add the following lines right before the longjmp in fpe(). #ifdef MSC _fpreset #endif /* MSC */ The floating point exceptions of past lives were leaving garbage on the chip, eventually resulting in a stack overflow.