Opened 13 months ago

Last modified 13 months ago

#15634 infoneeded bug

GHCi: Segmentation fault Data.List.sum large number

Reported by: ksallberg Owned by:
Priority: normal Milestone: Research needed
Component: GHCi Version: 8.0.1
Keywords: segfault Cc: bgamari
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description (last modified by ksallberg)

Hello, first bug report here, so please let me know what I should provide. I tried to search for this but didn't find it.

kristian@snabbadatorn:~$ ghci
GHCi, version 8.0.1: http://www.haskell.org/ghc/  :? for help
Prelude> [1..100]
[1,2,3,4,5,6,7,8,9,10,11,12... and so on
Prelude> sum [1..10000000]
50000005000000
Prelude> sum [1..100000000]
Segmentation fault

Machine: Google compute engine, n1-highcpu-8 (8 vCPUs, 7.2 GB memory),

uname -r: 4.9.0-8-amd64

kristian@snabbadatorn:~$ lsb_release -a
No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux 9.5 (stretch)
Release:	9.5
Codename:	stretch
kristian@snabbadatorn:~$ ghci --version
The Glorious Glasgow Haskell Compilation System, version 8.0.1

Similar problem in older GHC version, although GHCi at least does not exit:

Amazon ec2, r4.8xlarge, 32 cores:

GHCi, version 7.10.3: http://www.haskell.org/ghc/  :? for help
Prelude> sum [1..100000000]
*** Exception: stack overflow
Prelude>
ubuntu@ip-172-31-21-176:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 16.04.5 LTS
Release:        16.04
Codename:       xenial
ubuntu@ip-172-31-21-176:~$ uname -r
4.4.0-1065-aws

Change History (10)

comment:1 Changed 13 months ago by ksallberg

Description: modified (diff)

comment:2 Changed 13 months ago by ksallberg

Description: modified (diff)

comment:3 Changed 13 months ago by ksallberg

Description: modified (diff)

comment:4 Changed 13 months ago by osa1

Stack overflow is expected. Prelude.sum is implemented using foldl which is leaky and will overflow the stack at some point. Try this:

~ $ ghci
GHCi, version 8.4.3: http://www.haskell.org/ghc/  :? for help
Loaded GHCi configuration from /home/omer/rcbackup/.ghci
λ:1> foldl (+) 0 [1..100000000]
*** Exception: stack overflow
λ:2> import Data.List
λ:3> foldl' (+) 0 [1..100000000]
5000000050000000

The segfault is an actual bug. Would it be possible for you to try this with GHC HEAD or at least 8.4.3? I tried with both and also with 8.0.1, but couldn't reproduce the segfault. If you can build GHC HEAD, it'd also be helpful to get a backtrace by doing this:

  • vim $(which ghc)
  • Replace the last line with this: exec gdb --args "$executablename" -B"$topdir" ${1+"$@"}
  • Run ghci using ghc --interactive
  • On segfault type bt<enter>, and paste the backtrace.
Last edited 13 months ago by osa1 (previous) (diff)

comment:5 Changed 13 months ago by ksallberg

Thank you for the directions. I will try building GHC HEAD as soon as I can, and get back here.

comment:6 Changed 13 months ago by bgamari

I suspect that this is a duplicate of #15060 which will be fixed in 8.6.1.

comment:7 Changed 13 months ago by osa1

Status: newinfoneeded

ksallberg, can you try with GHC 8.6 beta instead? If bgamari is right then the segfault should be fixed in 8.6 beta 1.

comment:8 Changed 13 months ago by ksallberg

The following happened when I used GHCi from https://downloads.haskell.org/~ghc/8.6.1-beta1/

(specifically ghc-8.6.0.20180810-x86_64-deb8-linux.tar.xz)

Note that this is on the Google cloud machine speficied above.

kristian@snabbadatorn:/$ ./usr/local/bin/ghci
GHCi, version 8.6.0.20180810: http://www.haskell.org/ghc/  :? for help
Prelude> sum [1..100000000]
<interactive>: internal error: Unable to commit 1048576 bytes of memory
    (GHC version 8.6.0.20180810 for x86_64_unknown_linux)
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
Aborted
Last edited 13 months ago by ksallberg (previous) (diff)

comment:9 Changed 13 months ago by osa1

Cc: bgamari added

This is basically a mmap() failure (mmap() returning MAP_FAILED). Whether this is expected or not probably depends on your configuration (how much the process allowed to allocate etc.). Perhaps bgamari knows how to see whether this is expected or not.

comment:10 Changed 13 months ago by bgamari

Indeed this is not expected; ideally we would throw a proper exception here (which we should presumably do when the test program is compiled).

Note: See TracTickets for help on using tickets.