Opened 4 years ago

Closed 3 years ago

#8276 closed bug (fixed)

Building Haddock documentation panics with perf build on x86_64 Linux

Reported by: jstolarek Owned by: thoughtpolice
Priority: high Milestone: 7.10.2
Component: Documentation Version: 7.7
Keywords: Cc: kazu@…, bgamari@…, jan.stolarek@…, andreas.voellmy@…, leroux@…, johan.tibell@…, johnw@…
Operating System: Unknown/Multiple Architecture: x86_64 (amd64)
Type of failure: Compile-time crash Test Case:
Blocked By: Blocking:
Related Tickets: #10301 Differential Rev(s):
Wiki Page:

Description (last modified by jstolarek)

After setting BuildFlavor = perf in build.mk compilation ends with a panic:

"/home/luite/buildtest/ghc-clean-buildtest/ghc/inplace/bin/haddock" --odir="libraries/ghc-prim/dist-install/doc/html/ghc-prim" --no-tmp-comp-dir --dump-interface=libraries/ghc-prim/dist-install/doc/html/ghc-prim/ghc-prim.haddock --html --hoogle --title="ghc-prim-0.3.1.0: GHC primitives" --prologue="libraries/ghc-prim/dist-install/haddock-prologue.txt"   --optghc=-hisuf --optghc=dyn_hi --optghc=-osuf --optghc=dyn_o --optghc=-hcsuf --optghc=dyn_hc --optghc=-fPIC --optghc=-dynamic --optghc=-H32m --optghc=-O --optghc=-package-name --optghc=ghc-prim-0.3.1.0 --optghc=-hide-all-packages --optghc=-i --optghc=-ilibraries/ghc-prim/. --optghc=-ilibraries/ghc-prim/dist-install/build --optghc=-ilibraries/ghc-prim/dist-install/build/autogen --optghc=-Ilibraries/ghc-prim/dist-install/build --optghc=-Ilibraries/ghc-prim/dist-install/build/autogen --optghc=-Ilibraries/ghc-prim/. --optghc=-optP-include --optghc=-optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h --optghc=-package --optghc=rts-1.0 --optghc=-package-name --optghc=ghc-prim --optghc=-XHaskell98 --optghc=-XCPP --optghc=-XMagicHash --optghc=-XForeignFunctionInterface --optghc=-XUnliftedFFITypes --optghc=-XUnboxedTuples --optghc=-XEmptyDataDecls --optghc=-XNoImplicitPrelude --optghc=-O2 --optghc=-no-user-package-db --optghc=-rtsopts --optghc=-odir --optghc=libraries/ghc-prim/dist-install/build --optghc=-hidir --optghc=libraries/ghc-prim/dist-install/build --optghc=-stubdir --optghc=libraries/ghc-prim/dist-install/build --source-module=src/%{MODULE/./-}.html --source-entity=src/%{MODULE/./-}.html#%{NAME}   libraries/ghc-prim/./GHC/Classes.hs  libraries/ghc-prim/./GHC/CString.hs  libraries/ghc-prim/./GHC/Debug.hs  libraries/ghc-prim/./GHC/Magic.hs  libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.hs  libraries/ghc-prim/./GHC/PrimWrappers.hs  libraries/ghc-prim/./GHC/IntWord64.hs  libraries/ghc-prim/./GHC/Tuple.hs  libraries/ghc-prim/./GHC/Types.hs libraries/ghc-prim/dist-install/build/autogen/GHC/Prim.hs +RTS -tlibraries/ghc-prim/dist-install/doc/html/ghc-prim/ghc-prim.haddock.t --machine-readable
Haddock coverage:
 100% (  1 /  1) in 'GHC.IntWord64'
  78% (  7 /  9) in 'GHC.Types'
   3% (  2 / 63) in 'GHC.Tuple'
   0% (  0 /  3) in 'GHC.Debug'
   0% (  0 /351) in 'GHC.PrimopWrappers'
   2% (  1 / 43) in 'GHC.PrimWrappers'
  17% (  1 /  6) in 'GHC.CString'
  31% (170 /540) in 'GHC.Prim'
 100% (  3 /  3) in 'GHC.Magic'
  38% (  6 / 16) in 'GHC.Classes'
haddock: internal error: haddock: panic! (the 'impossible' happened)
  (GHC version 7.7.20130912 for x86_64-unknown-linux):
	Static flags have not been initialised!
        Please call GHC.newSession or GHC.parseStaticFlags early enough.

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

make[1]: *** [libraries/ghc-prim/dist-install/doc/html/ghc-prim/ghc-prim.haddock] Error 1
make[1]: *** Waiting for unfinished jobs....
make: *** [all] Error 2

I've seen this problem before, but I thought that it was related to my patch. Now I got it on master branch and Luite reported the same problem on #ghc (log above is actually his).

A workaround for this is disabling building of documentation in "perf" section of build.mk.

Attachments (1)

hack_unparsed_staticflags.patch (3.4 KB) - added by darchon 4 years ago.

Download all attachments as: .zip

Change History (53)

comment:1 Changed 4 years ago by jstolarek

Description: modified (diff)

comment:2 Changed 4 years ago by bos

Affecting me, too.

comment:3 Changed 4 years ago by bos

Priority: normalhigh

comment:4 Changed 4 years ago by jstolarek

Kazu also reports this on ghc-devs and gives possible cause:

"It seems to me that this bug is relating to the followings:

Why did the initial value of v_opt_C_ready in GHCI change?"

comment:5 Changed 4 years ago by kazu-yamamoto

Cc: kazu@… added

comment:6 Changed 4 years ago by SimonHengel

Not sure whether I have the right picture here, but could it be that if you use the GHC API from GHCi we now end up with one single set of static flags that is shared between GHCi and the GHC API session (maybe caused by GHCi now using the dyn libs)?

comment:7 Changed 4 years ago by SimonHengel

To be precise with static flags I mean v_opt_C and v_opt_C_ready.

comment:8 Changed 4 years ago by bgamari

Cc: bgamari@… added

comment:9 Changed 4 years ago by kazu-yamamoto

I guess that a7f9930a24a91cfb5e2579867e5a0b1d83b5a947 by jstolarek introduced this bug. Since I cannot revert this patch due to the changes after this patch, I could not verify yet.

Changed 4 years ago by darchon

comment:10 Changed 4 years ago by darchon

I've attached a "hack" for haddock that makes the reported error go away. What it does, is only restore the static flags when it's likely that 'parseStaticFlags' will be called again. Now when I run "make" I get the same error as #8320.

My guess is that there is some interaction between the use of 'staticFlags' in GHC's error reporting and the exception handling code in haddock (the use of 'finally'). Since I don't really understand what's going on, I'm classifying my patch as a hack.

Last edited 4 years ago by darchon (previous) (diff)

comment:11 Changed 4 years ago by jstolarek

Cc: jan.stolarek@… added

How interesting that most bugs that hit me are the ones I myself introduced. Unfortunately at the moment I don't have time to look into this, because I'm fixing profiling (also broken by me). I wouldn't go with any hacky solutions here - we just need to figure out what is exactly going on and fix it properly. It would be good to have a small test case for this. I think this might be a good recipe: https://github.com/sol/doctest-haskell/pull/60#issuecomment-24287554

comment:12 Changed 4 years ago by kazu-yamamoto

I think this should be fixed in the GHC side. And I think I can take a time to look into this in the next week.

comment:13 Changed 4 years ago by jstolarek

Yes, I also think that the fix should be done in GHC. Kazu, I think that code posted by you in the comment I linked will make a perfect testcase for this bug (provided it is correct).

comment:14 Changed 4 years ago by kazu-yamamoto

I investigated this today and I think a7f9930a24a91cfb5e2579867e5a0b1d83b5a947 is OK. I don't know where this change comes from. But the current behavior is correct according to its document. Should we fix this in haddock side?

comment:15 Changed 4 years ago by darchon

The problem is that pretty-printing (code in Outputable.hs) an error tries to access the staticFlag "-dppr-debug". For some weird reason, the staticFlags are not parsed when the error message is converted to a String; that's the reason for this bug.

The error that it is trying to print is #8320, but I don't think the error would only show up for that particular failure. Perhaps this error didn't reveal itself earlier because #8320 is not a so called SourceError exception (Which are handled before staticFlags are restored), but an interface-file error related exception. GHC exceptions other than SourceError exceptions are caught at the very top of function hierarchy, when the staticFlags are already reverted to their unparsed state.

What my patch does is not revert static flags to their unparsed state in the withGhc code of haddock. It makes this particular error go away, but it is not a proper fix.

Also I want to point out that this bug, and the problem reported in https://github.com/sol/doctest-haskell/issues/59, are each others inverse: where the conflicting code in this bug expects staticFlags to be parsed, "kazu's" code expects the staticFlags not to be parsed yet.

Last edited 4 years ago by darchon (previous) (diff)

comment:16 Changed 4 years ago by darchon

A "better" patch for haddock can be found here: https://gist.github.com/christiaanb/6687503

comment:17 Changed 4 years ago by kazu-yamamoto

Does anyone know the reason why the initial value of v_opt_C_ready in GHCi change?

For GHCi 7.6.3:

% ghci -package ghc
> import StaticFlags (v_opt_C_ready)
> import Data.IORef
> readIORef v_opt_C_ready 
False

For GHCi head:

% ghci -package ghc
> import StaticFlags (v_opt_C_ready)
> import Data.IORef
> readIORef v_opt_C_ready 
True

I don't understand why this value can stay False in GHCi 7.6.3.

And I don't know which commit changed the behavior.

comment:18 Changed 4 years ago by thoughtpolice

This is something to do with GHCi linking in HEAD.

Note the behavior Kazu observed:

GHCi, version 7.7.20130924: 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 array-0.4.0.2 ... linking ... done.
Loading package deepseq-1.3.0.2 ... linking ... done.
Loading package bytestring-0.10.3.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.20130924 ... linking ... done.
Prelude> import StaticFlags 
Prelude StaticFlags> import Data.IORef 
Prelude StaticFlags Data.IORef> readIORef v_opt_C_ready 
True

But when we compile it as a program:

$ cat test.hs
import StaticFlags (v_opt_C_ready)
import Data.IORef

main = readIORef v_opt_C_ready >>= print
$ ~/ghc/ghc-pristine/inplace/bin/ghc-stage2 -O2 -package ghc test.hs -fforce-recomp
[1 of 1] Compiling Main             ( test.hs, test.o )
Linking test ...
$ ./test
False

I think what is happening is that in the GHCi case, the linker is referring to the 'outer' GHCi in which we are running our session, as opposed to the 'inner' session in which we try to read the flag.

I'm investigating a little more.

comment:19 in reply to:  16 Changed 4 years ago by krakrjak

I am seeing this problem on Linux too. The "better" patch does work as well as the one attached to this bug, but it still leaves the issue found in bug #8320.

Last edited 4 years ago by krakrjak (previous) (diff)

comment:20 Changed 4 years ago by simonmar

Wow, we've got ourselves into a real mess here. There's a lot that I don't understand about all this saving/restoring of static flags stuff, but I count at least three separate bugs.

Bug 1: the Haddock panic that started this ticket. Why is Haddock saving and restoring the static flag settings? I can't even see how that would work, because we have CAFs that depend on the static flag settings (like opt_PprStyle_debug) and those can't be saved/restored. But in any case, making the static flags empty is causing the panic in staticFlags to trigger. I'm not clear on why we're calling withGhc twice in Haddock, and parsing all the flags twice etc.

Bug 2: When GHCi is dynamically linked and you load the ghc package, you are getting the same ghc package that GHCi itself is using, which is why the static flags are already set. This is a serious problem, because it means that we can't have separate static flags when using the ghc package from GHCi.

Bug 3: I also noticed CoreMonad.reinitializeGlobals while I was perusing the code. That is needed when we're doing static linking (two ghc packages) but not when we're doing dynamic linking (one ghc package). Shouldn't there be some logic to test that somewhere?

comment:21 Changed 4 years ago by SimonHengel

The saveStaticFlagGlobals/restoreStaticFlagGlobals was added by me 1 1/2 years ago, so that you can run createInterfaces several times within the same process. The motivation for this was to be able to run Doctests test suite from GHCi and rerun after :reload.

Doctest is not depending on Haddock anymore, but we now have similar code in Doctest (https://github.com/sol/doctest-haskell/blob/master/src/GhcUtil.hs).

comment:22 in reply to:  20 Changed 4 years ago by igloo

Replying to simonmar:

Bug 2: When GHCi is dynamically linked and you load the ghc package, you are getting the same ghc package that GHCi itself is using, which is why the static flags are already set. This is a serious problem, because it means that we can't have separate static flags when using the ghc package from GHCi.

Could be solved by dynamicifying the remaining static flags!

comment:23 Changed 4 years ago by AndreasVoellmy

Cc: andreas.voellmy@… added

comment:24 Changed 4 years ago by leroux

Cc: leroux@… added

comment:25 Changed 4 years ago by tibbe

Cc: johan.tibell@… added

comment:26 Changed 4 years ago by schell

I'm also seeing this issue, and it was fixed by using the workaround listed in the description.

comment:27 Changed 4 years ago by kazu-yamamoto

Compiling test.hs with dynamic linking results in False. Strange.

% ghc -O2 -package ghc test.hs -fforce-recomp
% ./test
False
% ghc -O2 -dynamic -package ghc test.hs -fforce-recomp
% ./test                                              
False

comment:28 Changed 4 years ago by thoughtpolice

Milestone: 7.8.1
Owner: set to thoughtpolice
Priority: highhighest

I'll be looking into this. After talking about it, me and SPJ are honestly just inclined to delete the whole save/restore static flag code, since it doesn't really seem like it works anyway (re: Simon M's point #1 above, regarding the CAFs that cannot be reset.) This doesn't change the reality of #2 though: with GHCi being dynamic, v_opt_C_ready will already be set in GHCi, since we only use one copy of the GHC package. But this would completely eliminate this problem, although DocTest needs to be updated then.

I attempted to begin removing the remaining static flags, but it quickly got extremely painful - removing the last ones will require quite a bit of refactoring as changing them to DynFlag entries makes the changes extremely pervasive (leaking into the wired-ins API, for example.)

Simon H, neither of us really understood what DocTest needs this for - to run createInterfaces several times apparently, but I'm not sure what the implications of that are. The remaining static flags only control very basic things, meant mostly for debugging - why does DocTest require saving them, exactly? Do you have a better suggestion of what should happen? Because this must be fixed, and I'm inclined to just delete broken code, rather than paper around it with more odd behavior that's difficult to comprehend.

comment:29 Changed 4 years ago by SimonHengel

Here is some (very simplified!) code from Doctest. In Haddock we have something similar.

parse :: [String] -> IO [TypecheckedModule]
parse args = bracket saveStaticFlagGlobals restoreStaticFlagGlobals $ \_ -> do
  args_ <- fst <$> parseStaticFlags (map noLoc args)
  runGhc (Just libdir) $ do
    (dynflags, files, _) <- getSessionDynFlags >>= (`parseDynamicFlags` args_)
    _ <- setSessionDynFlags dynflags
    mapM (`guessTarget` Nothing) (map unLoc files) >>= setTargets
    mods <- depanal [] False
    let sortedMods = flattenSCCs (topSortModuleGraph False mods Nothing)
    mapM (parseModule >=> typecheckModule >=> loadModule) sortedMods

(both Doctest and Haddock accept arbitrary GHC flags)

If we can safely ignore static flags altogether, and change this to

parse :: [String] -> IO [TypecheckedModule]
parse args = runGhc (Just libdir) $ do
  (dynflags, files, _) <- getSessionDynFlags >>= (`parseDynamicFlags` map noLoc args)
  _ <- setSessionDynFlags dynflags
  mapM (`guessTarget` Nothing) (map unLoc files) >>= setTargets
  mods <- depanal [] False
  let sortedMods = flattenSCCs (topSortModuleGraph False mods Nothing)
  mapM (parseModule >=> typecheckModule >=> loadModule) sortedMods

then I have no need for saveStaticFlagGlobals/restoreStaticFlagGlobals anymore.

comment:30 Changed 4 years ago by SimonHengel

Say, I would like to change Haddock like so: https://github.com/sol/haddock/commit/b03718b80f0366c1e495f52d9468019360a5cca9

Are we sure, that e.g. cabal-install never passes any static flags to Haddock? Otherwise we would get an error in line 337.

Last edited 4 years ago by SimonHengel (previous) (diff)

comment:31 Changed 4 years ago by JohnWiegley

Cc: johnw@… added

comment:32 Changed 4 years ago by carter

whats the current status of this ticket? Its affecting LOTs of people? Whats needed to push it along?

comment:33 Changed 4 years ago by SimonHengel

Austin, do you think what I proposed for the Haddock side of things is the way to go? I'm still puzzled what triggered the issue. A couple of weeks ago the documentation still build for me.

comment:34 Changed 4 years ago by thoughtpolice

Simon, this looks good to me. I'll merge this into Haddock and remove the {save,restore}StaticFlagGlobals code from GHC shortly.

comment:35 Changed 4 years ago by thoughtpolice

And I double checked Cabal - none of the remaining static flags are passed to Haddock in any way or even mentioned in Cabal.

Last edited 4 years ago by thoughtpolice (previous) (diff)

comment:36 Changed 4 years ago by thoughtpolice

hrrrrrrrrrrrrrgh.

OK, so this patch mostly works but there's a problem; several libraries use -fcpr-off which is a StaticFlag, meaning when it's passed to Haddock things mess up. Thinking about it, there are two other cases this could happen:

  • -fno-state-hack
  • -fno-opt-coercion

To change this StaticFlag would literally upset hundreds upon hundreds of call sites, and require substantial refactoring as it would introduce boot files and recursive dependencies across the frontend. Basically, the same thing I mentioned before.

SimonH, me and Edsko are also a bit confused on how this randomly popped up out of nowhere as well. Perhaps Christiaan's patch is the way to go, but I don't like keeping code like this around since it seems broke. I'm not sure we have much of an option, however, until I get around to removing the remaining StaticFlags. Which will take a while.

Alternatively, we can still remove all this code, and simply special-case Haddock and DocTest to totally ignore these flags and just not pass them to GHC. While they do affect how the optimizers work, I'm do not believe this could affect either Haddock or DocTest in any conceivable situations - but you would know more.

Thoughts?

Last edited 4 years ago by thoughtpolice (previous) (diff)

comment:37 Changed 4 years ago by SimonHengel

If we can add a function

discardStaticFlags :: [String] -> [String]

that removes static flags from a given list of arguments (including any arguments given to them, if any, not sure if there are static flags that take arguments) to the GHC API, then I'm fine with ignoring them in Haddock/Doctest.

Medium term it would still be nice to get rid of static flags completely, of course.

Last edited 4 years ago by SimonHengel (previous) (diff)

comment:38 Changed 4 years ago by thoughtpolice

Yes, I can do this.

And I agree (with you and Ian) that removing all the StaticFlags would be preferrable - it's just unfortunately a very large change to remove the last of them.

comment:39 Changed 4 years ago by Austin Seipp <austin@…>

In 16c401137a0d2aa803a5806493889056538c2de4/ghc:

Nuke {save,restore}StaticFlagGlobals.

As discussed in #8276, this code was somewhat broken because while you
could always revert the actual argument list, you can never revert the
CAFs upon which they are based - so really this didn't buy you much.

However, Haddock in particular expects to be able to parse GHC flags,
including static flags, and used this code to do so. In its place, we
instead have discardStaticFlags, which will safely remove any of the
remaining 5 flags from a list of arguments. Haddock instead discards
these, as they aren't related to anything it does anyway (mostly
controlling debugging output and some basic optimizer phases.)

This fixes #8276. In the future, we will eventually completely remove
the remaining StaticFlags, removing the need for this fix. Unfortunately
these changes will be quite invasive and require more time.

Signed-off-by: Austin Seipp <austin@well-typed.com>

comment:40 Changed 4 years ago by thoughtpolice

Simon, I've done this. Would you please review https://github.com/ghc/haddock/commit/c6faeae064668125721b0d5e60f067f90c538933 - which is based on the patch you provided? It merely uses discardStaticFlags to remove the problematic flags before running GHC via the API.

If it looks good, I think we can close this.

comment:41 Changed 4 years ago by SimonHengel

Looks good to me. :)

comment:42 Changed 4 years ago by thoughtpolice

Resolution: fixed
Status: newclosed

Excellent! Thank you for being so cooperative Simon!

Everyone else, this should be Fixed for Good Now.

comment:43 Changed 3 years ago by RyanGlScott

I still experience this panic on GHC 7.8.2 with Windows x86_64:

$ ghci
GHCi, version 7.8.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.
λ> import StaticFlags
λ> import Data.IORef
λ> readIORef v_opt_C_ready
Loading package array-0.5.0.0 ... 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.5.1 ... linking ... done.
Loading package Win32-2.3.0.2 ... linking ... done.
Loading package filepath-1.3.0.2 ... linking ... done.
Loading package old-locale-1.0.0.6 ... linking ... done.
Loading package time-1.4.2 ... linking ... done.
Loading package directory-1.2.1.0 ... linking ... done.
Loading package pretty-1.1.1.1 ... linking ... done.
Loading package process-1.2.0.0 ... linking ... done.
Loading package Cabal-1.18.1.3 ... 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.1 ... 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.8.2 ... linking ... done.
False
λ> staticFlags
ghc.exe: panic! (the 'impossible' happened)
  (GHC version 7.8.2 for x86_64-unknown-mingw32):
        Static flags have not been initialised!
        Please call GHC.parseStaticFlags early enough.

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

But not with GHC 7.8.2 on Linux x86_64:

$ ghci
GHCi, version 7.8.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.
λ> import StaticFlags
λ> import Data.IORef
λ> readIORef v_opt_C_ready
Loading package array-0.5.0.0 ... 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.5.1 ... linking ... done.
Loading package filepath-1.3.0.2 ... linking ... done.
Loading package old-locale-1.0.0.6 ... linking ... done.
Loading package time-1.4.2 ... linking ... done.
Loading package directory-1.2.1.0 ... linking ... done.
Loading package pretty-1.1.1.1 ... linking ... done.
Loading package process-1.2.0.0 ... linking ... done.
Loading package Cabal-1.18.1.3 ... 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.1 ... 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.8.2 ... linking ... done.
True
λ> staticFlags
[]

This has caused problems for me when running programs such as HERMIT on Windows, since at some point, parseStaticFlagsFull seems to be called during program execution. A workaround is to call initStaticOpts manually somewhere in the program, but I feel like that shouldn't be necessary.

comment:44 Changed 3 years ago by RyanGlScott

Owner: thoughtpolice deleted
Resolution: fixed
Status: closednew

comment:45 Changed 3 years ago by RyanGlScott

Here is a minimal plugin example which triggers the error (the full code is here):

module TestPlugin (plugin) where

import CoreMonad
import GhcPlugins
import HscTypes
import Outputable

plugin :: Plugin
plugin = defaultPlugin {
  installCoreToDos = install
}

install :: [CommandLineOption] -> [CoreToDo] -> CoreM [CoreToDo]
install _ todo = do
  reinitializeGlobals
  putMsgS "Hello!"
  return $ CoreDoPluginPass "Say module name" pass : todo

pass :: ModGuts -> CoreM ModGuts
pass guts = do
  dflags <- getDynFlags
  putMsgS "Will this crash on Windows?"
  putMsgS $ showPpr dflags (mg_module guts)
  putMsgS "Nope"
  return guts

Here is the output:

$ ghc Main.hs -fplugin=TestPlugin
[1 of 1] Compiling Main             ( Main.hs, Main.o ) [TestPlugin changed]
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package array-0.5.0.0 ... 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.5.1 ... linking ... done.
Loading package Win32-2.3.0.2 ... linking ... done.
Loading package filepath-1.3.0.2 ... linking ... done.
Loading package old-locale-1.0.0.6 ... linking ... done.
Loading package time-1.4.2 ... linking ... done.
Loading package directory-1.2.1.0 ... linking ... done.
Loading package pretty-1.1.1.1 ... linking ... done.
Loading package process-1.2.0.0 ... linking ... done.
Loading package Cabal-1.18.1.3 ... 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.1 ... 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.8.2 ... linking ... done.
Loading package ghc-plugin-test-0.1.0.0 ... linking ... done.
Hello!
Will this crash on Windows?
ghc.exe: panic! (the 'impossible' happened)
  (GHC version 7.8.2 for x86_64-unknown-mingw32):
        Static flags have not been initialised!
        Please call GHC.parseStaticFlags early enough.

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

comment:46 Changed 3 years ago by RyanGlScott

I can confirm that this bug still exists on GHC 7.8.3 on Windows x86_64.

comment:47 Changed 3 years ago by thoughtpolice

Milestone: 7.8.17.8.4
Priority: highesthigh

Thanks, moving to 7.8.4.

comment:48 Changed 3 years ago by thoughtpolice

Owner: set to thoughtpolice

comment:49 Changed 3 years ago by thoughtpolice

Milestone: 7.8.47.10.1

Moving (in bulk) to 7.10.4

comment:50 Changed 3 years ago by thoughtpolice

Milestone: 7.10.17.10.2

Moving to GHC 7.10.2.

comment:51 Changed 3 years ago by mjmrotek

Hello,

A similar panic also happens when running Liquid Haskell http://goto.ucsd.edu/~rjhala/liquid/haskell/blog/about/ on a file that uses the Units of Measure plugin https://github.com/adamgundry/uom-plugin

liquid: liquid: panic! (the 'impossible' happened)
  (GHC version 7.10.1 for x86_64-unknown-linux):
	Static flags have not been initialised!
        Please call GHC.parseStaticFlags early enough.

comment:52 in reply to:  51 Changed 3 years ago by thoughtpolice

Resolution: fixed
Status: newclosed

Okay, so I'm closing this ticket and opening a new one in its place for the new plugins failure, which is totally unrelated to the original issue in this ticket: Please see #10301 for further discussion.

Note: See TracTickets for help on using tickets.