GitLab

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 94ab5d29)[[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

Trac metadata

Trac field	Value
Version	7.7
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture