[ ghc-Bugs-537295 ] div 0 0 give exception / endless loop

[SourceForge.net]

Bugs item #537295, was opened at 2002-03-31 01:36
Message generated for change (Comment added) made by simonmar
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=108032&aid=537295&group_id=8032

Category: Runtime System
Group: 5.02
Status: Open
Resolution: Remind
Priority: 5
Submitted By: geoff (snailtalk)
Assigned to: Simon Marlow (simonmar)
Summary: div 0 0 give exception / endless loop

Initial Comment:
There is a problem with the div in ghc, to reproduce:

start ghci and type div n 0 where n is any integer (so
div 3 0 would work)

on a linux box it gives a floating point exception
while on a BSD 4.4 box it gives and endless loop using
about 87 % of cpu.

I have verified this on both the latest release
(5.02.2) and 5.02.1.



----------------------------------------------------------------------

>Comment By: Simon Marlow (simonmar)
Date: 2003-04-28 13:01

Message:
Logged In: YES 
user_id=48280

Could you elaborate?  I can't see a bug.

On my FreeBSD box I just tried:

Prelude> :m +GHC.Base
Prelude GHC.Base> I# (0# `divInt#` 0#)
zsh: 487 floating point exception (core dumped)  ghci

I'm not sure what your 'signal' program is supposed to be 
illustrating: GHC doesn't catch SIGFPE at all so I don't think 
any behaviour of the SIGFPE handler could possibly be 
affecting us.

Furthermore, GHC 5.04.3 turns normal Int division-by-zero 
into an exception:

Prelude> div 0 0
*** Exception: divide by zero

(which is why I had to call the primitive directly above).

----------------------------------------------------------------------

Comment By: geoff (snailtalk)
Date: 2003-04-23 19:07

Message:
Logged In: YES 
user_id=20846

It has come to my attention that it is still not fixed in
5.04.2 (my fault for not reading the exact nature of the
fix).  I assume because for SIGFPE in Unix, the result is
undefined after return from the signal handler.

Here is some sample code to demonstrate:

usage: signal (+|-)u (signal|sigaction)

options:
+u  : uninstall signal in sighandler
-u   : don't uninstall signal in sighandler
signal:  install using signal()
sigaction:  install using sigaction()
 
so for example, signal +u sigaction would install the
handler using sigaction and uninstall the signal in the
signal handler.  The signal is hardcoded to SIGFPE.


----------------------------------------------------------------------

Comment By: Simon Marlow (simonmar)
Date: 2002-07-02 11:30

Message:
Logged In: YES 
user_id=48280

Fixed by not ignoring SIGFPE.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=108032&aid=537295&group_id=8032