home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / unix / bsd / 5615 < prev    next >
Encoding:
Text File  |  1992-09-12  |  2.6 KB  |  80 lines
  1. Newsgroups: comp.unix.bsd
  2. Path: sparky!uunet!spool.mu.edu!wupost!udel!sbcs.sunysb.edu!sbcs!stark
  3. From: stark@cs.sunysb.edu (Gene Stark)
  4. Subject: Program dies with FP Exception
  5. Message-ID: <STARK.92Sep13002650@sbstark.cs.sunysb.edu>
  6. Sender: usenet@sbcs.sunysb.edu (Usenet poster)
  7. Nntp-Posting-Host: sbstark
  8. Organization: SUNY at Stony Brook Computer Science Dept.
  9. Date: Sun, 13 Sep 1992 05:26:50 GMT
  10. Lines: 68
  11.  
  12. Here's a tough one I've been trying to track down -- maybe somebody out there
  13. who knows more can guess what is going on.
  14.  
  15. I am running 386BSD on a 486/33 system with 4MB RAM and a 210MB Connor IDE
  16. drive.  A program I was working on dies on Signal 8 (Floating point exception)
  17. in a perfectly repeatable fashion.  It is not so easy to tell where the
  18. exception actually comes from, though, because the signal seems to be getting
  19. delivered to the process much later, when it is leaving the system after
  20. a call to "write".  I haven't been able to get a small test program that
  21. repeats the bug, however there seem to be several crucial elements involved:
  22.  
  23.     (1)  A call to "atof", which returns a double that is then
  24.         stored in a temporary on the stack.  Removing the call
  25.         removes the error.
  26.  
  27.     (2)  The actual magnitude of the number being converted by "atof".
  28.         I found that the string "1e10" and "1e12" cause the error,
  29.         but "1e9", "1e6", and "0.0" do not.
  30.  
  31.     (3)  Some later "write" system calls.  The signal is actually
  32.         delivered on the fourth call to write after the atof.
  33.         What is happening in the interim is just C code without
  34.         any other system calls.  I do not know what causes the
  35.         signal to get delivered when it actually does.
  36.  
  37. After a lot of debugging, I boiled the problem down to this section of
  38. source code:
  39.  
  40.     lp->token.value.flot = atof("1e10");
  41.  
  42. This compiles (no optimization) to the following:
  43.  
  44.     pushl $LC10
  45.     call _atof
  46.     addl $-8,%esp
  47.     fstpl (%esp)        # This instruction seems to be the culprit
  48.     popl %eax
  49.     popl %edx
  50.     movl 8(%ebp),%ecx
  51.     movl %eax,20(%ecx)
  52.     movl %edx,24(%ecx)
  53.  
  54. Removing the "fstpl" instruction removes the error.  Placing the code:
  55.  
  56.     pushl $1
  57.     call _sleep
  58.  
  59. immediately after the "fstpl" instruction also removes the error.
  60.  
  61. Taking the code out of context and putting it in a small test program
  62. does not produce the error, so presumably there is some interaction with
  63. the virtual memory state.
  64.  
  65. I also tried putting the instruction
  66.  
  67.     movl $0,(%esp)
  68.  
  69. just after the fstpl instruction, on the theory that maybe the fstpl
  70. was causing a page fault with bad consequences, but this did not eliminate
  71. the error.
  72.  
  73. So, are these enough clues that somebody who knows more than I do can
  74. guess what the problem might be?  Any help appreciated.
  75.  
  76.                         - Gene Stark
  77.  
  78.  
  79.  
  80.