#7500: GHC: internal error: getMBlock: mmap: Operation not permitted ----------------------------------+------------------------------------ Reporter: guest | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+------------------------------------ Changes (by rwbarton): * status: new => patch Comment: I dug into this some more. In the kernel I have installed (Debian 2.6.32-5-686), mmap selects an address for the new mapping based on the hint address and the process's current mappings, but without regard to `mmap_min_addr`. Then, if the address selected was less than `mmap_min_addr`, mmap may return EPERM, depending on the SELinux configuration. I believe the same applies to at least all 32-bit x86 Linux versions. In my kernel, it doesn't seem that trying to mmap again with no hint address can ever help Linux find the unmapped areas above `mmap_min_addr`. I'm not sure whether this holds in modern Linux, which has an entirely new algorithm for finding unmapped areas. But in any case, it is easy enough to try a second mmap with no hint address. I've attached a patch which, on Linux, tries to do a second mmap if it receives EPERM, and treats EPERM as an out-of-memory condition. With the patch, the example program allocates 2929 MB and then exits with the message {{{ part.hs: out of memory (requested 1048576 bytes) }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7500#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler