[GHC] #7500: GHC: internal error: getMBlock: mmap: Operation not permitted

[GHC]

#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