Open maksbotan opened 4 years ago
Weird indeed! Maybe it is making stabs in the dark, but maybe starting with an empty module (with all defs to undefined?) and adding code in little steps could drive to catch the offending fragment
Hmm, I found what breaks it. Here's how to reproduce:
module TH.hs
:
module TH where
import Data.Aeson (Value)
import Data.Yaml (decodeFileThrow)
import Language.Haskell.TH (Exp, Q, runIO)
import Language.Haskell.TH.Syntax (addDependentFile, lift)
loadEnum :: FilePath -> Q Exp
loadEnum path = do
val <- runIO $ decodeFileThrow path :: Q Value
lift ([] :: [String])
module Exp.hs
:
{-# LANGUAGE TemplateHaskell #-}
module Exp where
import TH
list :: [String]
list = $(loadEnum "test.txt")
file test.txt
(this is valid yaml):
123
456
With this I get the same behavior on Exp.hs
. If I comment the line with runIO
in TH.hs
, the problem is gone.
Maybe it's worth noting that I first observed this on a module that just imports list defined in Exp.hs, therefore I had no idea that the problem is in TH.
Thanks for investigating and minimize the reproduction case. For completeness: the crash is triggered when hie tries to load a module that imports, even transitively, TemplateHaskell definitions that runs IO.
Yes, looks like that. Where do you think the problem is -- in hie, ghc-mod or maybe ghc itself?
I think the problem is that we work with a copy of the file in a temporary directory. I suspect it is not able to find the file "test.txt".
@alanz sadly, it's probably more complicated than that.
Here's what I checked:
readFile
instead of decodeFileThrow
from Data.Yaml -- worksreadFile
-- worksval <- runIO $ (decodeStrict <$> BS.readFile path) :: Q (Maybe Value)
(decodeStrict
from aeson) -- still worksdecodeFileEither
and decodeFileThrow
from Data.Yaml
-- crashBS.readFile path >>= decodeThrow
-- crashdecodeEither <$> BS.readFile path
-- also crashSo probably the problem is somewhere in that module: http://hackage.haskell.org/package/yaml-0.11.2.0/docs/src/Data.Yaml.html
That's totally crazy.
I checked if i fails with latest snoyberg/yaml@d0a2ba62a (yaml-0.11.2.0) -- it does.
I tried with system-libyaml
-- fails as well.
I was able to find a place in yaml
that breaks:
If I change the function to:
runParser parser = do
let mark = YamlMark 0 0 0
yield $ MarkedEvent EventStreamStart mark mark
yield $ MarkedEvent EventDocumentStart mark mark
yield $ MarkedEvent (EventScalar (B8.pack "!!!!") NoTag Plain Nothing) mark mark
yield $ MarkedEvent EventDocumentEnd mark mark
yield $ MarkedEvent EventStreamEnd mark mark
return ()
-- i.e. return constant yaml without actually parsing file (but still with opening, initing C library and freeing it afterwards). And in this case, HIE does not crash. @snoyberg, maybe you can debug this problem on yaml's side?
Is there any option or patch to make HIE output when or how exactly does ghc-mod fail?
Hello.
FYI, this still happens on latest master (92ac896029a5ba5f740ebca168533c83848548c6).
Now HIE does not crash, it just doesn't work.
There is this line in the log:
2020-01-13 18:38:37.500783 [ThreadId 28] - Scheduler thread exited unexpectedly: loadObj "/private/var/folders/xm/wymzs8212vd2z4w239yz0kxr0000gn/T/ghc98091_0/ghc_4.o": failed
After that, judging by the log, it gets my commands like "hover", but does not answer.
Full log with --debug --vomit
: hie.log
How can I debug this further/
The issue you are encountering looks like https://github.com/haskell/haskell-ide-engine/issues/1520 and currently, there is not much to debug it. The problem might occur on Modules that import Paths_*
.
Well, I don't know if the two are related.
I found out that my issue is related to using "yaml" package - see above for proof. It is some weird interaction between yaml, its ffi stuff, TH and hie.
The error also reminds me #1207
2020-01-14 18:58:50.5547596 [ThreadId 4] - <--2--{"jsonrpc":"2.0","params":{"value":{"kind":"report","percentage":0.9629629629629629,"message":"Haskell.Ide.Engine.Version"},"token":0},"method":"$/progress"}
2020-01-14 18:58:51.8267596 [ThreadId 25] - Scheduler thread exited unexpectedly: loadObj "C:\\TEMP\\ghc11780_0\\ghc_20.o": failed
The cabal project loading stops in Haskell.Ide.Engine.Version
that suspiciously uses TemplateHaskell, using a definition that runs IO (to call the git program and get the last commit hash)
Just ran into this in a Yesod Application. The standard Model.hs
gets stuck because of PersistEntitySyntax.
I too am having issues on a Yesod Application, but I can't tell which file it's crashing on based on the log output.
Sadly, this still happens with latest master (35f62cffb6bae6c3f86113cb0c55f52b7192689d), LTS-15.5 and GHC-8.8.3.
I am also experiencing this issue with some TH code that performs IO. I managed to get 2 different crash messages:
hie-8.4.4: loadObj: /tmp/ghc88723_0/ghc_145.o: file doesn't exist
2020-05-01 11:29:20.322143244 [ThreadId 28] - Scheduler thread exited unexpectedly: loadObj "/tmp/ghc88723_0/ghc_145.o": failed
2020-05-01 11:10:31.876190063 [ThreadId 29] - Scheduler thread exited unexpectedly: expectJust getLinkDeps
CallStack (from HasCallStack):
error, called at compiler/utils/Maybes.hs:55:27 in ghc:Maybes
expectJust, called at compiler/ghci/Linker.hs:710:28 in ghc:Linker
Well, at least I don't feel alone, as I am also experiencing the expectJust getLinkDeps
on some Template Haskell code! :-(
hie works fine on all modules in my project except one. I see this in logs (
--debug --vomit
):As you can see, hie (ghc-mod?) just dies without printing any logs. Unfortunately, I can't share my code as this is a private project at my job. Can you give any hints on how to get more info from hie?
I tried removing some code from the module, but wasn't able to find minimal offending piece...
I'm on latest master (f7e0db0e10) with GHC-8.6.3, my project uses LTS-13.6 from stack. I use nvim with coc.nvim.