#8604: Some stack/vmem limits (ulimit) combinations causing GHC to fail ----------------------------------+---------------------------------- Reporter: clavin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Other | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by int-e): Replying to [comment:1 carter]:
ghc allocates the stack on the heap, so this may be tripping a corner case somehow...
There are two kinds of stacks. The STG stack (one per Haskell thread) is indeed allocated on the heap, grown dynamically, and its maximum size is governed by the '-K' RTS option. But each OS thread also has its own C stack and the size of that is determined by the stack size resource limit by default: ({{{createOSThread()}}} in {{{rts/posix/OSThreads.c}}} uses {{{pthread_create()}}} with no specific thread attributes. Quoting {{{man pthread_create}}}: {{{ On Linux/x86-32, the default stack size for a new thread is 2 megabytes. Under the NPTL threading implementation, if the RLIMIT_STACK soft resource limit at the time the program started has any value other than "unlimited", then it determines the default stack size of new threads. }}} Other implementations may differ. I'm not sure whether or how this should be dealt with by ghc. In some circumstances, a large C stack is required (depending on used foreign libraries), and currently the soft stack resource limit is the knob to turn in that case. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8604#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler