Skip to content

GHC crashes on start with some values of RLIMIT_AS

Summary

With some values of address space limit (RLIMIT_AS, ulimit -v) on x86-64 Linux, GHC 8.10.2 (as well as 8.10.1) crashes on startup with the following error:

ghc: internal error: Itimer: Failed to spawn thread: Cannot allocate memory
    (GHC version 8.10.2 for x86_64_unknown_linux)
    Please report this as a GHC bug:  https://www.haskell.org/ghc/reportabug
Aborted

This happens even for ghc -v. For example, it fails for ulimit -v $((1024 * 1024)), but not for ulimit -v $((1000 * 1000)).

Using strace the problem seems to stem from the fact that GHC attempts to allocate as much of the available address space as possible (probably for its heap?) and it later canniot allocate stack for one of its threads:

mmap(0x4200000000, 1074790400, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = -1 ENOMEM (Cannot allocate memory)
mmap(0x4200001000, 940572672, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x4200001000
madvise(0x4200001000, 940572672, MADV_DONTNEED) = 0
madvise(0x4200001000, 940572672, MADV_DONTDUMP) = 0
munmap(0x4200001000, 1044480)           = 0
munmap(0x4238100000, 4096)              = 0
mmap(0x4200100000, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4200100000
madvise(0x4200100000, 1048576, MADV_WILLNEED) = 0
madvise(0x4200100000, 1048576, MADV_DODUMP) = 0
mmap(0x4200200000, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4200200000
madvise(0x4200200000, 1048576, MADV_WILLNEED) = 0
madvise(0x4200200000, 1048576, MADV_DODUMP) = 0
mmap(NULL, 8392704, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = -1 ENOMEM (Cannot allocate memory)

Full strace is attached: ghc.strace.

Steps to reproduce

  1. on a Linux machine set address space limit in the current shell to 1 GiB: ulimit -v $((1024 * 1024))
  2. run any ghc or ghci command, e.g., ghc -v
  3. GHC crashes with the aforementioned error message.
  4. set address space limit to 1000000 kB: ulimit -v 1000000
  5. run ghc -v
  6. it works with this settings

Expected behavior

It is expected that GHC works with (reasonable) address-space limits. I would also be reasonable for it to not attempt to eat all available address space.

Environment

  • GHC version used:

  • Operating System: Archlinux, Debian 10 (stable)

  • System Architecture: x86-64

Edited by Vladimír Štill
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information