Opened 10 years ago

Closed 9 years ago

Last modified 6 years ago

#449 closed bug (wontfix)

Very big integer arithmetic crashes GHCi on Windows and Mac

Reported by: simonpj Owned by: simonmar
Priority: normal Milestone: 6.4.2
Component: Runtime System Version: 6.4.1
Keywords: Cc:
Operating System: Windows Architecture: Unknown/Multiple
Type of failure: Test Case:
Blocked By: Blocking:
Related Tickets: Differential Revisions:

Description (last modified by simonmar)

With GHC 6.4, interpreted or compiled, on Windows and 
Mac OS X, 
evaluating the expression (4^(4^44))::Integer causes a 
crash.

On Unix, it just goes out to lunch and eats memory, 
which seems more plausible.


On Mac, the message is:
    ___         ___ _
   / _ \ /\  /\/ __(_)
  / /_\// /_/ / /  | |      GHC Interactive, version 6.4, for 
Haskell 98.
/ /_\\/ __  / /___| |      http://www.haskell.org/ghc/
\____/\/ /_/\____/|_|      Type :? for help.

Loading package base-1.0 ... linking ... done.
Prelude> 4^(4^44)::Integer
bash: [539: 1] tcsetattr: Operation not supported
Segmentation fault

Change History (4)

comment:1 Changed 10 years ago by nobody

Logged In: NO 

GHC6.4 also causes a segfault on my linux box...

$ ghci
   ___         ___ _
  / _ \ /\  /\/ __(_)
 / /_\// /_/ / /  | |      GHC Interactive, version 6.4, for
Haskell 98.
/ /_\\/ __  / /___| |      http://www.haskell.org/ghc/
\____/\/ /_/\____/|_|      Type :? for help.

Loading package base-1.0 ... linking ... done.
Prelude> 4^(4^44)
Segmentation fault

comment:2 Changed 9 years ago by simonmar

  • Description modified (diff)
  • Milestone set to 6.4.2
  • Owner changed from nobody to simonmar
  • severity changed from normal to minor
  • Status changed from assigned to new
  • Version changed from None to 6.4.1

comment:3 Changed 9 years ago by simonmar

  • Architecture set to Unknown
  • difficulty set to Unknown
  • Operating System set to Windows
  • Resolution changed from None to wontfix
  • Status changed from new to closed

I believe this is the process running out of C stack space. GMP allocates some temporaries on the C stack, and it looks like this is overlowing the C stack.

Here's the backtrace I got:

(gdb) where
#0  0x00da19f3 in probe ()
#1  0x01e02008 in ?? ()
#2  0x00d9bc36 in __gmpn_sqr_n (prodp=0x2002008, up=0x1e02008, un=262145)
    at mul.c:79
#3  0x00d9bf49 in __gmpn_mul (prodp=0x2002008, up=0x1e02008, un=262145, 
    vp=0x1e02008, vn=262145) at mul.c:111
#4  0x00d99953 in __gmpz_mul (w=0xeb1130, u=0xeb1170, v=0xeb1150) at mul.c:122
#5  0x00d7deb5 in timesIntegerzh_fast ()
#6  0x00eb1130 in pinned_object_block ()
#7  0x00eb1170 in mp_result2 ()
#8  0x00eb1150 in mp_tmp_w ()
#9  0x00000000 in ?? () from 
(gdb) up
#1  0x01e02008 in ?? ()
(gdb) 
#2  0x00d9bc36 in __gmpn_sqr_n (prodp=0x2002008, up=0x1e02008, un=262145)
    at mul.c:79
79            tspace = (mp_ptr) TMP_ALLOC (2 * (un + BITS_PER_MP_LIMB) * BYTES_PER_MP_LIMB);

and it appears that TMP_ALLOC() is mapped to alloca() when using GCC (see gmp-impl.h).

comment:4 Changed 6 years ago by simonmar

  • Architecture changed from Unknown to Unknown/Multiple
Note: See TracTickets for help on using tickets.