#7500: GHC: internal error: getMBlock: mmap: Operation not permitted ----------------------------------+------------------------------------ Reporter: guest | Owner: Type: bug | Status: new 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: ----------------------------------+------------------------------------ Comment (by rwbarton): I was able to reproduce this on a 32-bit Linux system by setting `mmap_min_addr` to 2MB (`sudo /sbin/sysctl -w vm.mmap_min_addr=$((2*1048576))`). 1MB was not small enough. `mmap_min_addr` is a security measure that forbids a user program from mapping pages at or near address 0. (This eliminates an easy mechanism for exploiting kernel NULL (or near-NULL) dereferences: the running program's address space is still mapped when in kernel mode, so an attacker can map a page at 0, trigger a NULL dereference in the kernel and trick the kernel into doing something bad rather than oopsing.) Based on strace output, it seems that when the hint address to mmap is near mmap_min_addr and there is not enough room left nearby above mmap_min_addr, Linux might either return EPERM or give you a totally different memory block. So this is not exactly a simple case of running out of memory. It's likely that when we receive an EPERM from mmap with a hint address, then falling back to no hint address might give us another block. Then we could report an out-of-memory error if the mmap with no hint address also returned EPERM (though it might just return ENOMEM, instead). However, in my testing, the test program in the report was able to allocate 3068 MB of virtual address space when `mmap_min_addr` was not an issue (<= 1MB) and 2929 MB when it got EPERM due to `mmap_min_addr` (2MB), so there was only 139 MB of virtual address space left that it could have scrounged up with this strategy. I think that simply treating EPERM as an out-of-memory error would be an acceptable fix. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7500#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler