[ ghc-Bugs-429369 ] BIG Bignum => segfault
noreply@sourceforge.net
noreply@sourceforge.net
Wed, 06 Jun 2001 10:04:16 -0700
Bugs item #429369, was updated on 2001-06-01 10:20
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=108032&aid=429369&group_id=8032
Category: Runtime System
Group: 5.00
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Jón Fairbairn (jonfairbairn)
Assigned to: Julian Seward (sewardj)
Summary: BIG Bignum => segfault
Initial Comment:
18:12:18 pictogramme: ghci
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version
5.00.1, For Haskell 98.
/ /_\/ __ / /___| | http://www.haskell.org/ghc/
\____/\/ /_/\____/|_| Type :? for help.
Loading package std ... linking ... done.
Prelude> odd (2^100000000)
Segmentation fault (core dumped)
18:14:36 pictogramme:
----------------------------------------------------------------------
>Comment By: Jón Fairbairn (jonfairbairn)
Date: 2001-06-06 10:04
Message:
Logged In: YES
user_id=215048
Hmmm. I think Julian is responding to the bug I emailed him
privately, rather than the one I filed here. At least, last
time I counted there are more than 68 000 000 atoms in the
known universe (and 2^68 000 000) has only that many digits
:-).
I expected it would be some sort of resource exhaustion
problem. It does, indeed crash sooner if I reduce the system
stack. (and what I take to be a bug in bash stops me
increasing it back :-()
----------------------------------------------------------------------
Comment By: Julian Seward (sewardj)
Date: 2001-06-06 09:31
Message:
Logged In: YES
user_id=50143
Jon
Thank you for trying to compute, with ghci, a number
which probably has more digits than there are atoms in
the (known) universe.
After some investigation we noticed that part way through
this computation, the stack pointer register was being
moved down by 3.8 MB (!) Upshot: GMP stupidly uses
alloca in some places. The intermediate values from
this computation are so large that they presumably cause
a C stack overflow. If you set your max stack size for
Unix processes to a smaller value, the examples
correspondingly die sooner.
Finally (for your entertainment) the offending line of
code is line 112 in gmp/mpz/mul.c.
Workaround: don't use such large numbers :)
Seriously, it's pretty cruddy that GMP behaves like
this. It ought to fail gracefully when it runs out of
memory, even if it is asked to do something as
ridiculous as this. I'll file a bug report with them.
J
----------------------------------------------------------------------
Comment By: Jón Fairbairn (jonfairbairn)
Date: 2001-06-05 07:20
Message:
Logged In: YES
user_id=215048
I get the correct answer for values I've tried up to about
68000000, at which point I get the above crash.
The binary is from the rpm:
15:08:22 pictogramme: rpm -q ghc
ghc-5.00.1-1
The os is RedHat 7.1:
15:15:03 pictogramme: cat /etc/issue
Red Hat Linux release 7.1 (Seawolf)
Kernel 2.4.2-2 on an i586
the processor is Julian's old AMD K6-300
There's 128M memory and about double that swap in two
pieces:
15:15:14 pictogramme: free
total used free shared
buffers cached
Mem: 126632 123084 3548 0
21788 16100
-/+ buffers/cache: 85196 41436
Swap: 267576 80 267496
I've tried telling the kernel that it has only 64M and
turning off one of the swaps, but in all cases the bug
starts with the same size of number.
(gdb -c core; backtrace just produces hex, so I shan't
include that here).
----------------------------------------------------------------------
Comment By: Simon Marlow (simonmar)
Date: 2001-06-04 01:52
Message:
Logged In: YES
user_id=48280
I can't repeat this one on i386-unknown-linux, it gives the
answer False as expected (after about 10 minutes!).
Could you give us more info: which distribution did you
install (RPM or binary dist), on what platform (processor
model might be important).
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=108032&aid=429369&group_id=8032