Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
  • GHC GHC
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 5,413
    • Issues 5,413
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 600
    • Merge requests 600
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Releases
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Glasgow Haskell CompilerGlasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #8376
Closed
Open
Issue created Sep 28, 2013 by darchon@trac-darchon

Static Executable + GHC API (+ Dynamic Linking?) gives Segfault

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
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking