[GHC] #8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault
#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
#8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault ----------------------------------+---------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by darchon): When I build a completely statically-linked GHC, using the following build.mk: {{{ SRC_HC_OPTS = -O -H64m GhcStage1HcOpts = -O -fasm GhcStage2HcOpts = -O2 -fasm GhcHcOpts = -Rghc-timing GhcLibHcOpts = -O2 GhcLibWays = v HADDOCK_DOCS = NO DYNAMIC_BY_DEFAULT = NO DYNAMIC_GHC_PROGRAMS = NO }}} , the above described segfaults no longer appear. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8376#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault ----------------------------------+---------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Changes (by simonmar): * priority: normal => highest * milestone: => 7.8.1 Comment: I expect there's a decision being made about whether to link dynamically based on `DYNAMIC_GHC_PROGRAMS` rather than whether the program was compiled with `-dynamic` or not. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8376#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
I expect there's a decision being made about whether to link dynamically
#8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault ----------------------------------+---------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by darchon): Replying to [comment:2 simonmar]: based on `DYNAMIC_GHC_PROGRAMS` rather than whether the program was compiled with `-dynamic` or not. The `haddock` executables referred to in the bug report are built using a `cabal install`; they do not refer to a `haddock` executable build during a `make` in the `ghc` build-tree. I'm not building `haddock` during my build of `ghc` (ref. the `HADDOCK_DOCS=NO` in my `build.mk`). And I assume the `DYNAMIC_GHC_PROGRAMS` has no effect on the dynamic- linking decision made by `cabal`. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8376#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault ----------------------------------+---------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by darchon): On Linux (GHC-b84fbabb0cad88a5b1ae62a53e04075383bc11f4), using a statically-linked `haddock`, I get: {{{ ~/devel/lens/src (master *)$ haddock -v3 Control/Lens/Internal/ByteString.hs Creating interfaces... Haddock coverage: Checking module Control.Lens.Internal.Level... Creating interface... 100% ( 6 / 6) in 'Control.Lens.Internal.Level' <MORE LOG MESSAGES> 100% ( 6 / 6) in 'Control.Lens.Internal.Getter' Checking module Control.Lens.Internal.Fold... <command line>: can't load .so/.DLL for: /home/baaijcpr/multi- ghc/7.7.20131002/lib/ghc-7.7.20131002/ghc-prim-0.3.1.0/libHSghc- prim-0.3.1.0-ghc7.7.20131002.so (/home/baaijcpr/multi- ghc/7.7.20131002/lib/ghc-7.7.20131002/ghc-prim-0.3.1.0/libHSghc- prim-0.3.1.0-ghc7.7.20131002.so: undefined symbol: stg_forkOnzh) }}} Also on Linux, the dynamically-linked `haddock` runs _without_ failure. I also want to note that `Control.Lens.Internal.Fold` is one of the source-files in the `lens` package that contains a `{-# ANN ... #-}` annotation. Removing the annotation makes the statically-linked haddock go through until another file with a `{-# ANN ... #-}` annotation is found, and subsequently stops with the same failure. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8376#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault ----------------------------------+---------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by darchon): I want to point out that this bug will affect very _few_ users of GHC, at least initially. The reason: `haddock` will normally be build using dynamic-linking in the normal build/distribution process of GHC; and the dynamically-linked version shows no problems. Only if a user reinstalls `haddock`, e.g. doing a `cabal install haddock --reinstall`, will he encounter the described bug. That is because static- linking is (currently) the default for all executables built using `cabal`. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8376#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault ----------------------------------+---------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by simonmar): The problem is not in Haddock, it's the GHC API. GHC's linker is using dynamic linking even when the program using the GHC API is linked statically, because it is using the value of `DYNAMIC_GHC_PROGRAMS`, which is set when GHC is built. We might not be able to support using the GHC API from a statically linked binary on all platforms, because it depends on having a working RTS linker, and that's what we wanted to move away from. But I think we can support it at least on ELF platforms where the RTS linker works for most things. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8376#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault ----------------------------------+---------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by darchon): Replying to [comment:6 simonmar]:
The problem is not in Haddock, it's the GHC API. GHC's linker is using dynamic linking even when the program using the GHC API is linked statically, because it is using the value of `DYNAMIC_GHC_PROGRAMS`, which is set when GHC is built. Indeed, I initially noticed the bug in my own program that uses the GHC API. I just reference `haddock` in the bug report as it is such a widely used tool.
If the problem is not fixed before the release of 7.8.1, perhaps it could at least be mentioned in the release notes that it is advised that executables (transitively) using the GHC API should be linked dynamically? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8376#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault ----------------------------------+---------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by igloo): Or better yet, have the functions that do dynamic loading give an error if not compiled for the appropriate way. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8376#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault ----------------------------------+---------------------------------- Reporter: darchon | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Changes (by simonmar): * owner: => simonmar -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8376#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault ----------------------------------+---------------------------------- Reporter: darchon | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by nomeata): I don’t fully understand all of this, but it seems that this patch breaks the build how I set it up on travis. Error message is {{{ HC [stage 2] libraries/dph/dph-lifted-copy/dist- install/build/Data/Array/Parallel/PArray/PData.o Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.4.0.2 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package bytestring-0.10.4.0 ... linking ... done. Loading package containers-0.5.3.1 ... linking ... done. Loading package filepath-1.3.0.2 ... linking ... done. Loading package old-locale-1.0.0.5 ... linking ... done. Loading package time-1.4.1 ... linking ... done. Loading package unix-2.7.0.0 ... linking ... done. Loading package directory-1.2.0.1 ... linking ... done. Loading package pretty-1.1.1.0 ... linking ... done. Loading package process-1.2.0.0 ... linking ... done. Loading package Cabal-1.18.1 ... linking ... done. Loading package binary-0.7.1.0 ... linking ... done. Loading package bin-package-db-0.0.0.0 ... linking ... done. Loading package hoopl-3.10.0.0 ... linking ... done. Loading package hpc-0.6.0.1 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package transformers-0.3.0.0 ... linking ... done. Loading package ghc-7.7.20131011 ... linking ... ghc-stage2: /home/travis/build/nomeata/ghc-complete/ghc- validate/compiler/stage2/build/libHSghc-7.7.20131011.a: unknown symbol `rts_isDynamic' ghc-stage2: unable to load package `ghc-7.7.20131011' make[1]: *** [libraries/dph/dph-lifted-copy/dist- install/build/Data/Array/Parallel/PArray/PData.o] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2 }}} Full log at https://s3.amazonaws.com/archive.travis- ci.org/jobs/12411908/log.txt and commands to build the code at https://github.com/nomeata/ghc-complete/blob/master/validate.sh Could this caused by your patch? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8376#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault ----------------------------------+---------------------------------- Reporter: darchon | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by int-e): Replying to [comment:12 nomeata]:
Could this caused by your patch?
I just encountered the same problem. {{{rts/Linker.c}}} does not yet know about {{{rts_IsDynamic}}}. Adding one line fixes the problem for me: {{{ diff --git a/rts/Linker.c b/rts/Linker.c index f2672d7..116c924 100644 --- a/rts/Linker.c +++ b/rts/Linker.c @@ -1225,6 +1225,7 @@ typedef struct _RtsSymbolVal { SymI_HasProto(rts_unsafeGetMyCapability) \ SymI_HasProto(rtsSupportsBoundThreads) \ SymI_HasProto(rts_isProfiled) \ + SymI_HasProto(rts_isDynamic) \ SymI_HasProto(setProgArgv) \ SymI_HasProto(startupHaskell) \ SymI_HasProto(shutdownHaskell) \ }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8376#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault ----------------------------------+---------------------------------- Reporter: darchon | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by thoughtpolice): Good catch. Please update - fixed in c5262a12a2d3568cc00ffa47a686b3c8e015b2c5 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8376#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault ----------------------------------+---------------------------------- Reporter: darchon | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Changes (by thoughtpolice): * owner: simonmar => thoughtpolice -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8376#comment:15 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault ----------------------------------+---------------------------------- Reporter: darchon | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.2 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Changes (by thoughtpolice): * milestone: 7.8.1 => 7.8.2 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8376#comment:16 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault ----------------------------------+---------------------------------- Reporter: darchon | Owner: thoughtpolice Type: bug | Status: closed Priority: highest | Milestone: 7.8.3 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed Comment: This should now be fixed (the MachO and PE linkers saw some good improvements, and Mach works fine - Windows isn't dynamically linked just yet anyway). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8376#comment:18 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault ----------------------------------+---------------------------------- Reporter: darchon | Owner: thoughtpolice Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Changes (by thoughtpolice): * milestone: 7.8.3 => 7.8.1 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8376#comment:19 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault ----------------------------------------+---------------------------------- Reporter: darchon | Owner: thoughtpolice Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------+---------------------------------- Comment (by JeanPhilippeMoresmau): I have a similar problem. Using 7.8.3 on Ubuntu, evaluating an expression using the GHC API works if the executable is build with -dynamic, and fails with a segFault if it's build statically. Should I create a new ticket or modify this one? Since Hackage refuses packages that use the -dynamic flag because of a Cabal bug it's annoying (and -dynamic may not work on all OSes). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8376#comment:20 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault ----------------------------------------+---------------------------------- Reporter: darchon | Owner: thoughtpolice Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------+---------------------------------- Comment (by simonmar): @JeanPhilippeMoresmau I think you're probably running into #8935, which will be fixed in 7.8.4 and 7.10. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8376#comment:21 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault ----------------------------------------+---------------------------------- Reporter: darchon | Owner: thoughtpolice Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------+---------------------------------- Comment (by JeanPhilippeMoresmau): @simonmar unfortunately my bug is still present in 7.8.4 rc1 (ghc-7.8.3.20141119). I'll create a new ticket. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8376#comment:22 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#8376: Static Executable + GHC API (+ Dynamic Linking?) gives Segfault ----------------------------------------+---------------------------------- Reporter: darchon | Owner: thoughtpolice Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------+---------------------------------- Comment (by simonmar): Alas, I think the fix has not been committed yet. https://phabricator.haskell.org/D349 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8376#comment:23 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC