[GHC] #15808: Loading libraries with FFI exports may cause segfaults in the compiler if they are loaded far from the rts in memory.

GHC ghc-devs at haskell.org
Sat Nov 3 21:10:38 UTC 2018


#15808: Loading libraries with FFI exports may cause segfaults in the compiler if
they are loaded far from the rts in memory.
-------------------------------------+-------------------------------------
        Reporter:  AndreasK          |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.7
  (Linking)                          |
      Resolution:                    |             Keywords:
Operating System:  Windows           |         Architecture:  x86_64
 Type of failure:  Compile-time      |  (amd64)
  crash or panic                     |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------
Changes (by AndreasK):

 * priority:  high => normal
 * owner:  AndreasK => (none)


Comment:

 Fixing this won't be easy, so for the moment I will leave it as is.

 The main issue is that we try to jump from a loaded library to the rts.

 Now we have the problem that we end up with a memory layout of something
 like this:
 <compiler+rts> <... 2+GB of things ...> <libraries loaded for TH>

 Fixing the C stubs was reasonably easy. We can just tell gcc to use the
 large memory model making jumps 64bit sized.


 What I had failed to consider is that we also jump into the rts from
 regular haskell code.
 Now making sure all THIS code works well with a 64 bit address space
 sounds bad enough. But it also comes with performance costs as we increase
 code size. Given, probably not a big one but still.

 So even IF we fix this we would incurr a performance penalty for pretty
 much ALL haskell programs out there. So this seems like it's not worth it
 at the moment unless there are somehow a lot of "random" crashes out there
 which can be traced back to this issue.

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


More information about the ghc-tickets mailing list