[GHC] #8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault

[GHC]

#8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault
----------------------------------+----------------------------------
       Reporter:  darchon         |             Owner:
           Type:  bug             |            Status:  new
       Priority:  normal          |         Milestone:
      Component:  Compiler        |           Version:  7.7
       Keywords:                  |  Operating System:  MacOS X
   Architecture:  x86_64 (amd64)  |   Type of failure:  Runtime crash
     Difficulty:  Unknown         |         Test Case:
     Blocked By:                  |          Blocking:
Related Tickets:                  |
----------------------------------+----------------------------------
 I am getting segfaults when a statically linked executable uses a GHC API.
 When the same executable is however dynamically linked it runs without
 error.
 In case of the statically-linked version, I think that one of GHC API
 functions that tries to do dynamic-linking is causing the segfault.
 The reason why I think this, is because the segfault shows up when
 Template-Haskell is used, or when {{{ {-# ANN ... #-} }}} annotations are
 used.

 An example of this strange behaviour can be shown using haddock, and
 running it on the source-code for the lens library [1]:
 {{{
 ~/Documents/devel/lens/src (master *)$ haddock -v3
 Control/Lens/Internal/ByteString.hs
 Creating interfaces...
 Haddock coverage:
 Checking module Control.Lens.Internal.Setter...
 Creating interface...
  100% (  3 /  3) in 'Control.Lens.Internal.Setter'
 <MORE LOG MESSAGE>
 Checking module Control.Lens.Reified...
 Creating interface...
  100% ( 20 / 20) in 'Control.Lens.Reified'
 Checking module Control.Lens.Setter...
 Bus error: 10 <-- SEGFAULT
 }}}

 And the GDB output:
 {{{
 (gdb) run -v3 Control/Lens/Internal/ByteString.hs
 Starting program: /Users/christiaan/.ghc-
 config/cabal/7.7.20130924/bin/haddock -v3
 Control/Lens/Internal/ByteString.hs
 Reading symbols for shared libraries +++..............................
 done
 Creating interfaces...
 Haddock coverage:
 Checking module Control.Lens.Internal.Setter...
 Creating interface...
  100% (  3 /  3) in 'Control.Lens.Internal.Setter'
 <MORE LOG MESSAGES>
 Checking module Control.Lens.Reified...
 Creating interface...
  100% ( 20 / 20) in 'Control.Lens.Reified'
 Checking module Control.Lens.Setter...

 Program received signal EXC_BAD_ACCESS, Could not access memory.
 Reason: KERN_PROTECTION_FAILURE at address: 0x000000010828b982
 0x000000010828b982 in ?? ()
 }}}
 I should note that until now I've been unable to produce a _small_ test
 case that shows the above behaviour. The statically linked haddock
 actually runs successfully on many packages. The lens[1] package is the
 first widely used library that I've been able to get haddock to exhibit
 the above behaviour.

 Also, when I built a dynamically-linked version of haddock, it runs
 succesfully for the above test-case (and the other test-cases where the
 statically-linked version would give a segfault).
 The source-code for lens[1] contains many {{{ {-# ANN ... #-} }}}
 annotations; removing all those annotations make the statically-linked
 version of haddock run successfully, with out segfaults.
 Halfway through removing the {{{ {-# ANN ... #-} }}} annotation, I also
 encountered the following error:
 {{{
 Checking module Control.Lens.Fold...
 haddock: internal error: ARR_WORDS object entered!
     (GHC version 7.7.20130924 for x86_64_apple_darwin)
     Please report this as a GHC bug:
 http://www.haskell.org/ghc/reportabug
 Abort trap: 6
 }}}

 I've also encountered the segfault while running the statically-linked
 haddock on my own clash library [2]. In this case I think it might have
 something to do with the use of template-haskell. Again, running the
 dynamically-linked version of haddock does not show any problems.

 Here is some extra information about my development environment:[[BR]]
 OS: OS X 10.8.5[[BR]]
 X-Code: XCode CL-Tools 4.6.2[[BR]]
 GHC: GHC-HEAD (commit 94ab5d2984514f92dd919fbf3611a07d32105546)[[BR]]
 Output of {{{make show VALUE=GhcLibWays}}}: v dyn[[BR]]
 build.mk:
 {{{
 SRC_HC_OPTS     = -O -H64m
 GhcStage1HcOpts = -O -fasm
 GhcStage2HcOpts = -O2 -fasm
 GhcHcOpts       = -Rghc-timing
 GhcLibHcOpts    = -O2
 HADDOCK_DOCS    = NO
 }}}
 I create statically-linked binaries by setting {{{executable-dynamic}}} in
 {{{.cabal/config}}} to {{{False}}}[[BR]]
 I create dynamically-linked binaries by setting {{{executable-dynamic}}}
 in {{{.cabal/config}}} to {{{True}}}[[BR]]
 I created the {{{haddock}}} executables by running {{{cabal install}}} in
 {{{"up-to-date build tree of GHC"/utils/haddock}}}

 [1] https://github.com/ekmett/lens[[BR]]
 [2] http://hackage.haskell.org/package/clash-lib

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