Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#2880 closed bug (fixed)

GHC panic when printing Unique

Reported by: sebf Owned by:
Priority: normal Milestone:
Component: Compiler Version: 6.10.1
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


The following program causes panic:

    import UniqSupply
    main = mkSplitUniqSupply 'x' >>= print . uniqFromSupply

The error message is:

    ghcbug: ghcbug: panic! (the 'impossible' happened)
      (GHC version 6.10.1 for i386-apple-darwin):
	    Static flags have not been initialised!
            Please call GHC.newSession or GHC.parseStaticFlags early enough.

I have encountered this on an Apple MacBook with GHC 6.10.1 and could reproduce it on a Linux PC with the same GHC version.

The module UniqSupply comes from the ghc package which is hidden by default. So before compiling it (or running it in GHCi) type

    ghc-pkg expose ghc

in a shell.

Change History (3)

comment:1 Changed 9 years ago by batterseapower

I don't think this is actually a bug. Printing a Unique actually does require access to the static flags, so you need to initialize them as the panic suggests.

The relevant code is in Unique.lhs:

pprUnique :: Unique -> SDoc
pprUnique uniq
  | opt_SuppressUniques
  = empty	-- Used exclusively to suppress uniques so you 
  | otherwise	-- can compare output easily
  = case unpkUnique uniq of
      (tag, u) -> finish_ppr tag u (text (iToBase62 u))

Note the use of opt_SuppressUniques, a static flag, which pulls on the staticFlags thunk and hence causes the panic.

I'm not sure we actually intend UniqSupply et al. to be used outside the context of GHC session, so this behaviour does not surprise me...

You can probably fix it by doing:

import UniqSupply
import StaticFlagParser (parseStaticFlags)

main = do
  parseStaticFlags []
  mkSplitUniqSupply 'x' >>= print . uniqFromSupply

This will most likely continue to work in the future, but there are no guarantees :-)

comment:2 Changed 9 years ago by sebf

Resolution: fixed
Status: newclosed

Thank you for the clarifications! I have not been aware that using UniqSupply requires any additional initialization and thought the message referred to something that is usually done but forgotten.

What would be the preferred thing to do, when writing a library that needs unique identifiers? Reimplement them, put them on Hackage/github and hope that GHC experts find the time to optimize them like their own? A package on Hackage that can be used by ghc *and* other libraries seems preferable. But I don't know how easy or difficult it is to factor out uniques from ghc...

comment:3 Changed 9 years ago by batterseapower

Factoring out Uniques would be /fairly/ straightforward - I think the only surprising dependency of Uniques comes from that use of the static flag, which is only used when printing them. This is easily avoided by defining a new Show instance that does not use pprUnique.

However, I'm not sure we want GHC to have another dependency (and hence boot package), so we would probably not depend on that package ourselves - but you are welcome to copy the code :-)

Note: See TracTickets for help on using tickets.