Opened 13 years ago

Closed 13 years ago

Last modified 44 years ago

#550 closed bug (Wont Fix)

BIG Bignum => segfault

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

Description

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: 

Change History (4)

comment:1 Changed 13 years ago by simonmar

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).

comment:2 Changed 13 years ago by jonfairbairn

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:3 Changed 13 years ago by sewardj

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:4 Changed 13 years ago by jonfairbairn

  • Status changed from assigned to closed
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 :-()

Note: See TracTickets for help on using tickets.