#5748: ghci segfault on OS X after dlsym failed lookup
---------------------------------+------------------------------------------
Reporter: gwright | Owner: gwright
Type: bug | Status: patch
Priority: normal | Milestone:
Component: GHCi | Version: 7.2.1
Keywords: | Os: MacOS X
Architecture: Unknown/Multiple | Failure: GHCi crash
Difficulty: Unknown | Testcase:
Blockedby: | Blocking:
Related: |
---------------------------------+------------------------------------------
Comment(by gwright):
I backported my patch to 7.2.2, rebuilt the dependencies for my library
and tried my test program again. As expected, {{{ghci}}} now gives a
error, indicating that it can't find a symbol:
{{{
gwright-macbook> ghci Test.hs
GHCi, version 7.2.2: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
[1 of 1] Compiling Main ( Test.hs, interpreted )
Ok, modules loaded: Main.
*Main> x
Loading package bytestring-0.9.2.0 ... linking ... done.
Loading package transformers-0.2.2.0 ... linking ... done.
Loading package mtl-2.0.1.0 ... linking ... done.
Loading package array-0.3.0.3 ... linking ... done.
Loading package deepseq-1.2.0.1 ... linking ... done.
Loading package text-0.11.1.12 ... linking ... done.
Loading package parsec-3.1.2 ... linking ... done.
Loading package uniqueid-0.1.1 ... linking ... done.
Loading package Wheeler-0.1 ... linking ... <interactive>:
lookupSymbol failed in relocateSection (relocate external)
/Users/gwright/.cabal/lib/Wheeler-0.1/ghc-7.2.2/HSWheeler-0.1.o: unknown
symbol `_Wheelerzm0zi1_MathziSymbolicziWheelerziComplexity_Real_closure'
ghc: unable to load package `Wheeler-0.1'
*Main>
}}}
The unresolved symbol above is an algebraic data type used as a record
field to indicate if a symbol is real or complex. The original segfault I
saw was a failure to resolve the Show instance for the whole record.
So we're back to the original problem, without the embarrassing segfault.
One possibly relevant observation is that I had to write a number of
{{{.hs-boot}}} files to break circular module dependencies. I needed to
do this because my expression data type can, for example, contain tensor
symbols, and those tensor symbol can in turn have components that are
expressions. Could my {{{.hs-boot}}} files be at the root of this?
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5748#comment:8>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
