Skip to content

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
    • Help
    • Support
    • Submit feedback
  • Sign in / Register
GHC
GHC
  • Project
    • Project
    • Details
    • Activity
    • Releases
    • Cycle Analytics
    • Insights
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Charts
    • Locked Files
  • Issues 3,623
    • Issues 3,623
    • List
    • Boards
    • Labels
    • Milestones
  • Merge Requests 204
    • Merge Requests 204
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
    • Charts
  • Security & Compliance
    • Security & Compliance
    • Dependency List
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Charts
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • Glasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #10058

Closed
Open
Opened Feb 01, 2015 by Richard Eisenberg@rae
  • Report abuse
  • New issue
Report abuse New issue

Panic: Loading temp shared object failed

I ran into a panic when updating singletons for 7.10. I'm clueless as to what's going on here, so sorry for not minimizing the test case. A little testing has me convinced it's Template Haskell in some way.

To reproduce:

> git clone http://github.com/goldfirere/singletons.git
> cd singletons
> git checkout ghc-loading-panic-test-case
> cabal update
> cabal install --only-dependencies
> cabal configure
> cabal build
> cat dist/build/autogen/cabal_macros.h
# copy the value for CURRENT_PACKAGE_KEY from the end of cabal_macros.h
> cd tests/compile-and-dump
> ghc -c -this-package-key <package key from cabal_macros.h> -i../../dist/build -XTemplateHaskell Singletons/Maybe.hs

You will see something like

ghc: panic! (the 'impossible' happened)
  (GHC version 7.10.0.20150123 for x86_64-apple-darwin):
	Loading temp shared object failed: dlopen(/var/folders/ps/s45r2x1s6r15ws78py_zypl00000gn/T/ghc45837_0/libghc45837_1.dylib, 5): Symbol not found: _mtlzuJNaGzzEkFfL43R3LZZNRlPRm_ControlziMonadziReaderziClass_DZCMonadReader_con_info
  Referenced from: /var/folders/ps/s45r2x1s6r15ws78py_zypl00000gn/T/ghc45837_0/libghc45837_1.dylib
  Expected in: flat namespace
 in /var/folders/ps/s45r2x1s6r15ws78py_zypl00000gn/T/ghc45837_0/libghc45837_1.dylib

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

I've observed this on a Mac, but Travis has the same problem, so it's not strictly Mac-specific. You can see representative Travis output here.

Why am I doing such a crazy thing? It's part of the singletons test suite, where it's important to test the output of a run of ghc with -ddump-splices. Getting the test cases to compile against the built-but-not-yet-installed singletons object files should work with -this-package-key. I'm sure there's a better way to structure a testsuite, but this general technique works (with -package-name instead of -this-package-key) with 7.8.

Trac metadata
Trac field Value
Version 7.10.1-rc2
Type Bug
TypeOfFailure OtherFailure
Priority normal
Resolution Unresolved
Component Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system MacOS X
Architecture x86_64 (amd64)

Related issues

  • Discussion
  • Designs
Assignee
Assign to
7.10.1
Milestone
7.10.1
Assign milestone
Time tracking
None
Due date
None
5
Labels
bug P::highest RTS runtime crash Trac import
Assign labels
  • View project labels
Reference: ghc/ghc#10058