[GHC] #2972: ppc ghci segfaults at startup

[GHC]

#2972: ppc ghci segfaults at startup
------------------------+---------------------------------------------------
    Reporter:  cemeyer  |       Owner:  erikd     
        Type:  bug      |      Status:  new       
    Priority:  normal   |   Milestone:  _|_       
   Component:  GHCi     |     Version:  7.5       
    Keywords:           |          Os:  Linux     
Architecture:  powerpc  |     Failure:  GHCi crash
  Difficulty:  Unknown  |    Testcase:            
   Blockedby:           |    Blocking:            
     Related:           |  
------------------------+---------------------------------------------------

Comment(by erikd):

 Working from the point I left off, @benmcollins was able to determine that
 this segfault was being caused by the memory protection mechanism.

 Due to the requirement of "jump islands" to handle 24 bit relative jump
 offsets, GHCi on PowerPC does not use mmap() to load object files like the
 other architectures. Instead, it allocates memory using malloc() and
 fread() to load the object code. However there is a quirk in the GNU libc
 malloc() implementation. For memory regions over certain size (dynamic and
 configurable),
 malloc() will use mmap() to obtain the required memory instead of sbrk()
 and malloc's call to mmap() sets the memory readable and writable, but not
 executable. That means when GHCi loads code into a memory region that was
 mmapped instead of malloc-ed and tries to execute it we get a segfault.

 Ben's first approach to fixing this issue was to use mallopt() to force
 malloc() to avoid using mmap() regardless of the size of the allocation.
 This worked but was not optimal.

 Based on Ben's finding, I compiled GHC on x86-64 with USE_MMAP undefined
 and found that GHCi on x86-64 can be made to segfaults in exactly the same
 way as PowerPC.

 Ben then came up with a better solution, one that still uses mmap() but
 puts the jump island for an object code module at the end of the mmaped
 region for that object.

 I'm currently preparing a patch.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2972#comment:20>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler