ModOrigin: hidden module redefined

[pepeiborra]

I get a sporadic GHC panic while editing the module imports of a small project (ghc-check). This seems to be triggered only by very fast edits, .e.g. when using fd as a vim arpeggio for escape.

ghcide doesn't immediately crash after the panic, but diagnostics become stuck. After a while, ghcide will crash.

[DEBUG] Starting shakeRun (aborting the previous one took 0.00s)
ghcide: ghcide: panic! (the 'impossible' happened)
  (GHC version 8.8.3 for x86_64-unknown-linux):
	ModOrigin: hidden module redefined

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

This is on current HEAD:

ghcide version: 0.1.0 (GHC: 8.8.3) (PATH: /home/pepe/scratch/ghcide/dist-newstyle/build/x86_64-linux/ghc-8.8.3/ghcide-0.1.0/x/ghcide/build/ghcide/ghcide) (GIT hash: c7c39827d30db801201ebacf4093cd773e753637)
Starting LSP server...

[pepeiborra]

Probably some state in the ghc session is not completely thread-safe, or doesn't like being interrupted. What sort of guarantees does the ghc api offer here?

[ndmitchell]

Lots of state in the GHC session doesn't like being interrupted, although the guarantee is that you'll be fine - although it's a guarantee no one has tested or extensively relied upon before. TH used to have horrible issues with being interrupted. I imagine it's a case of tracking them down one by one.

[mpickering]

So the panic is coming from the Monoid instance for ModuleOrigin and Zubin tells me that these are the only three places the instance is used.

http://78.47.113.11/docs/html/libraries/ghc/src/GHC.Unit.State.html#line-1649
http://78.47.113.11/docs/html/libraries/ghc/src/GHC.Unit.State.html#line-1699
http://78.47.113.11/docs/html/libraries/ghc/src/GHC.Unit.State.html#line-1956

[pepeiborra]

Being able to see where an instance is being used is an awesome superpower, thanks!

[pepeiborra]

After looking at the code, my understanding is that we can work around the problem by avoiding interrupting calls to initPackages, which is called by setSessionDynFlags. But ghcide should only be calling setSessionDynFlags during cradle initialization, right? So the problem shouldn't arise when using ghc HEAD or possibly 8.10.1.

Indeed, I can confirm that the issue doesn't reproduce with ghc 8.10.1 for me at all. It does repro easily with ghc 8.8.3, where presumably theMonoid instance is being called in other contexts. In view of this, I would support closing this ticket as "Won't fix" and classifying this as a known issue with ghc < 8.10

[maksbotan]

Hm, can we make a backporting patch for 8.8.3? What commit fixed this for 8.10?

[pepeiborra]

By all means, if you or anyone else have the time and inclination, please go for it! I have little motivation since we have already upgraded to 8.10 at work.

[maksbotan]

Well, I would. Do you have any research on 8.8 to 8.10 changes? I fear bisecting would be too hard :/

[pepeiborra]

I haven’t done any research, sorry.

[maksbotan]

I've built 8.8.3 from source, planning to bisect, but could not reproduce the fail in cabal new-repl with it :/

[jneira]

We dont have a reproducible case and afaiu it is fixed for sure in ghc-8.10, should we keep open this?

[pepeiborra]

Closing as the issue is already fixed in GHC