Ghcide: ModBreaks.modBreaks_array not initialised

[remexre]

Tried to use ghcide on a cabal v2 project I hadn't tried it on before, in a bunch of files I now get:

  ModBreaks.modBreaks_array not initialised
  CallStack (from HasCallStack):
  error, called at compiler/ghci/ByteCodeTypes.hs:173:24 in ghc:ByteCodeTypes

when I run ghcide src.

My hie.yaml looks like:

cradle:
  cabal:
    component: "lib:thingy"

so nothing too fancy there.

[ndmitchell]

Which GHC version? Can you share the project?

[remexre]

8.6.5, unfortunately not

[mpickering]

Which version of ghcide are you using? Can you attempt to narrow down any unusual features your project is using, looks like it is using TemplateHaskell?

[remexre]

$ ghcide --version
ghcide version: 0.1.0 (GHC: 8.6.5) (PATH: /home/nathan/.cabal/store/ghc-8.6.5/ghcide-0.1.0-2f99b6d84ad46f26e6486d5df1d479b8198283a6e32788c1d40fde84c32e6df8/bin/ghcide)

heh, this project uses lots of extensions:

$ grep -hr LANGUAGE src | sort -u
{-# LANGUAGE ConstraintKinds #-}
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE DefaultSignatures #-}
{-# LANGUAGE DeriveAnyClass #-}
{-# LANGUAGE DeriveFunctor #-}
{-# LANGUAGE DeriveGeneric #-}
{-# LANGUAGE EmptyCase #-}
{-# LANGUAGE FlexibleContexts #-}
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
{-# LANGUAGE KindSignatures #-}
{-# LANGUAGE LambdaCase #-}
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE NoStarIsType #-}
{-# LANGUAGE OverloadedLists #-}
{-# LANGUAGE OverloadedStrings #-}
{-# LANGUAGE PolyKinds #-}
{-# LANGUAGE Rank2Types #-}
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE StandaloneDeriving #-}
{-# LANGUAGE TemplateHaskell #-}
{-# LANGUAGE TupleSections #-}
{-# LANGUAGE TypeApplications #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE TypeOperators #-}
{-# LANGUAGE TypeSynonymInstances #-}
{-# LANGUAGE UndecidableInstances #-}
{-# LANGUAGE UndecidableSuperClasses #-}

[mpickering]

Using a lot of extensions isn't going to be the reason for your problem. Perhaps if you are doing something unusual in TemplateHaskell code then that could be the cause of the issue. I would recommend trying master or my wip/object-files branch to see if either of those are an improvement. I'll have a look at that panic to see if I have any ideas.

[remexre]

I'll give those branches a try after lunch. We don't define anything w/ TH, it's only Aeson, lens, and deriving-compat.

[remexre]

Still get that behavior on master

[remexre]

oh, the wip/object-files branch seems to fix it!

[mpickering]

Thanks, this is just a workaround though as the bytecode generation path should still work.

I will merge the object files stuff into my fork and then you can try using that as well as it rebased onto master unlike wip/object-files.

[remexre]

okay, my declaration of success may have been premature; it's back now...

[bgamari]

I also see I think I have a reasonable hypothesis for what is happening here: the issue revolves around GHCi breakpoints.

The error itself comes from GHC.ByteCode.Types.emptyModBreaks, which contains information about the GHCi breakpoints defined in a module. emptyModBreaks defines the modBreaks_flags field, which contains an array (indexed by breakpoint index) which determines which breakpoints have been enabled by the user, as bottom.

There are a few uses of emptyModBreaks throughout GHC:

• during desugaring, GHC.HsToCore.Coverage.mkModBreaks may return emptyModBreaks if hscTarget /= HscInterpreted (in the case of ghcide hscTarget == HscNothing). However, I believe this should only be hit if some sort of coverage is needed (e.g. HPC or profling is enabled)
• in the interpreter, GHC.Runtime.Interpreter.getModBreaks may return emptyModBreaks if it can't find ModBreaks for the requested module

It's not yet clear to me which of these cases we are hitting.

[bgamari]

All of this is complicated by the fact that ghcide configures GHC with hscTarget == HscNothing and yet calls into the code generator regardless. Frankly, this seems like it is a violation of some sort of invariant. However, the meaning of hscTarget is so spongey that it's hard to say with any certainty.

Regardless, I just posted !3314 which should avoid the issue.

[ndmitchell]

@bgamari when we set the hscTarget we genuinely didn't call the code generator - I suspect that's just something that got missed.

3314 will fix it on GHC 8.12, but any idea how we hack it back on older versions? Or just rely on the fact it's not terribly common an error.

[bgamari]

@ndmitchell patch coming.

[bgamari]

For what it's worth, my partner and I ran into this pretty quickly on a large project with @mpickering's multi-component branch. That being said,

• It's generally agreed that my partner is cursed when it comes to stumbling into unexpected bugs
• Our project file enables debug information for profiling purposes; this enable's GHC's Coverage logic, opening the door to this bug. However, the same could happen if profiling or HPC support were enabled.

I've proposed one possible approach to work around the issue in #518. I have not yet tested this but will do so tonight.

Regardless, I'm happy to report that ghcide has been working wonderfully otherwise (modulo the known limitations of multi-component support which @mpickering is improving upon).

[RichardWarfield]

I ran into the same issue; based on @bgamari's hint above, I disabled debug symbols (i.e. removed the -g flag I had been passing to ghc) and this resolved the issue for me.

[wz1000]

I think this should be fixed by #836 since we don't run the bytecode generator anymore. Please reopen if this is not the case.