Opened 12 years ago

Closed 11 years ago

Last modified 44 years ago

#62 closed bug (Fixed)

div 0 0 give exception / endless loop

Reported by: snailtalk Owned by: simonmar
Priority: normal Milestone:
Component: Runtime System Version: 5.02
Keywords: Cc:
Operating System: Architecture:
Type of failure: Difficulty:
Test Case: Blocked By:
Blocking: Related Tickets:

Description

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.


Attachments (1)

signal.2.c (1.0 KB) - added by snailtalk 11 years ago.

Download all attachments as: .zip

Change History (6)

comment:1 Changed 12 years ago by simonmar

Logged In: YES 
user_id=48280

Fixed by not ignoring SIGFPE.

Changed 11 years ago by snailtalk

comment:2 Changed 11 years ago by snailtalk

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:3 Changed 11 years ago by simonmar

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:4 Changed 11 years ago by snailtalk

Logged In: YES 
user_id=20846

Yes.  Because when this bug was closed, it was stated that
it was fixed by ignoring SIGFPE (20020702).  Therefore, I
could only assume that was the fix (sorry I forgot to to
strace).  Anyway since the signal has nothing to with ghc,
let us not worry about it.

Is this exception behavior for div new in ghc 5.04.3? 
Because while this was marked as fixed in the bug tracking
system fixed in July '02, and since then 5.04.2 has been
released, and 5.04.2 (what I am using now) does not exhibit
the same behavior (for both div 0 0 and mod 0 0 case).

Loading package haskell98 ... linking ... done.
Prelude> div 0 0
zsh: floating point exception  ghci

$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 5.04.2
$ 

comment:5 Changed 11 years ago by simonmar

  • Status changed from assigned to closed
Logged In: YES 
user_id=48280

No.  When the bug was originally closed, the reason given 
was "Fixed by NOT ignoring SIGFPE."  (my emphasis).

The divide-by-zero exception was introduced in GHC 5.04.3.

Note: See TracTickets for help on using tickets.