Closed codygman closed 2 years ago
Hi, thanks for the bug report, could you attach the log where the error is shown?
I made a Dockerfile replicating (I thought) my setup. It now fails on a different error. Maybe this should be a different issue until we get back to the title issue :wink:
For now though here is my Dockerfile:
And here is the error:
2021-03-06 21:53:49.117975884 [ThreadId 975] INFO hls: File: /haskell-language-server/plugins/hls-eval-plugin/test/testdata/TLocalImport.hs
Hidden: no
Range: 1:1-2:1
Source: compiler
Severity: DsError
Message:
cabal: streamingProcess: runInteractiveProcess: exec: does not exist (No such file or directory)
2021-03-06 21:53:49.153687181 [ThreadId 2593] INFO hls: finish: User TypeCheck (took 0.25s)
2021-03-06 21:53:49.166418375 [ThreadId 2596] INFO hls: finish: GetHie (took 0.01s)
And here are the full logs:
Edit: I hope I included all relevant pieces here, but if not just ping me and I'll try to make a fully reproducible example.
This isn't a docker issue, it's a custom quasi quoter issue also related to a different GHC bug:
Given a quasiquoter:
module QuasiQuoter where
qq :: TH.QuasiQuoter
qq = TH.QuasiQuoter
{ TH.quoteDec = const $ fail "cannot be used as a declaration"
, TH.quoteExp = join . fmap liftWithText . fromText . Text.pack
, TH.quotePat = const $ fail "cannot be used as a pattern"
, TH.quoteType = const $ fail "cannot be used as a type"
}
-- | This shouldn't be necessary, but unfortunately you cannot lift values that
-- contain text because of a bug. Read more about the bug here:
-- <https://gitlab.haskell.org/ghc/ghc/-/issues/12596>. The workaround came
-- from here: <https://stackoverflow.com/a/38182444>.
liftWithText :: Data.Data a => a -> TH.Q TH.Exp
liftWithText =
let liftText = fmap (TH.AppE $ TH.VarE 'Text.pack) . TH.lift . Text.unpack
in TH.dataToExpQ $ fmap liftText . Data.cast
And then using it in Main.hs:
import QuasiQuoter (qq)
let x = [qq|foo bar|]
main = pure ()
Is enough to trigger this bug:
m32_allocator_init: Failed to map
(GHC version 8.10.4 for x86_64_unknown_linux)
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
On version 1.2 of hls I'm now seeing these helpful warnings:
GHC error in desugarer lookup in Ghci1:
Can't find interface-file declaration for variable $tcNonEmptyText
Probable cause: bug in .hi-boot file, or inconsistent .hi file
Use -ddump-if-trace to get an idea of which file caused the error
I tried running stack clean --full
and still get the error.
It looks like I get this issue when using hspec-discover
, the core dump that is:
haskell-language-server: mmap 131072 bytes at (nil): Cannot allocate memory
haskell-language-server: Try specifying an address with +RTS -xm<addr> -RTS
haskell-language-server: internal error: m32_allocator_init: Failed to map
(GHC version 8.10.4 for x86_64_unknown_linux)
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
Aborted (core dumped)
I asked about this issue with the GHC devs on https://gitlab.haskell.org/ghc/ghc/-/issues/19421, and they suggested that GHC 9.0.2 might fix it. Unfortunately it seems not to be the case.
At this point I'm looking for workarounds. Can anyone suggest a way to narrow down which part of a codebase causes it? I already tried commenting out the one custom QuasiQuoter I have and HLS still crashes.
I don't see anything helpful in /tmp/hls.log
, and my Emacs stderr buffer for HLS just shows the m32_allocator_init
message.
maybe building hls from source dinamically linked could help here, as in other th related issued
I already build dynamically linked due to https://github.com/haskell/haskell-language-server/issues/1982. Doesn't help in this case unfortunately.
You could try disabling all the plugins, or just using the ghcide
executable instead of haskell-language-server
I have tried both ghcide typecheck
and haskell-language-server typecheck
as standalone commands. Both work for a while and then crash with the m32_allocator_init
message.
The thing that makes this hard to debug is I have a large codebase and I can't figure out what module is causing this. Is there some way to figure out what module(s) it is processing before the crash?
I'd be happy to try disabling all the plugins, do you happen to know an easy way to do that? I saw one comment showing a massive config turning them off one by one, but I'm wondering if there's an easier way.
What does ghcide +RTS --info
say?
I'd be happy to try disabling all the plugins, do you happen to know an easy way to do that? I saw one comment showing a massive config turning them off one by one, but I'm wondering if there's an easier way.
I am afraid it is not, they have to be disabled one by one
What does
ghcide +RTS --info
say?
> ghcide +RTS --info
[("GHC RTS", "YES")
,("GHC version", "9.0.2")
,("RTS way", "rts_thr")
,("Build platform", "x86_64-unknown-linux")
,("Build architecture", "x86_64")
,("Build OS", "linux")
,("Build vendor", "unknown")
,("Host platform", "x86_64-unknown-linux")
,("Host architecture", "x86_64")
,("Host OS", "linux")
,("Host vendor", "unknown")
,("Target platform", "x86_64-unknown-linux")
,("Target architecture", "x86_64")
,("Target OS", "linux")
,("Target vendor", "unknown")
,("Word size", "64")
,("Compiler unregisterised", "NO")
,("Tables next to code", "YES")
,("Flag -with-rtsopts", "-I0 -A128M -T")
]
That's not a dynamically linked executable. Could you make sure to build locally with -dynamic
? Please see the docs at:
https://haskell-language-server.readthedocs.io/en/latest/troubleshooting.html#static-binaries
Oh wow. I had run ldd
on my executables and assumed they were sufficiently dynamically linked:
~/.local/bin λ ldd ghcide
linux-vdso.so.1 (0x00007ffc05b52000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ff8eb2fa000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007ff8eb2de000)
libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (0x00007ff8eb2af000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007ff8eb2a4000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007ff8eb29f000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff8eb296000)
libgmp.so.10 => /lib/x86_64-linux-gnu/libgmp.so.10 (0x00007ff8eb213000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff8eb027000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ff8eaed9000)
/lib64/ld-linux-x86-64.so.2 (0x00007ff8eb331000)
But now I've built it with stack install --stack-yaml stack-9.0.2.yaml --ghc-options "-dynamic"
, and there are a lot more dynamic link dependencies, like basically every Haskell library. I'm trying this version out now...
Hooray, a call to haskell-language-server typecheck
succeeded! This is awesome, thanks so much!!!
I am gonna close this issue as all compiler crashes seems to have the same root cause:
If any of you think the issue should not be included generically feel free to reopen it (with a brief explanation if possible) Thanks all!
Your environment
A docker container using
FROM amazonlinux:2.0.20200722.0
.Output of
haskell-language-server --probe-tools
orhaskell-language-server-wrapper --probe-tools
:Which lsp-client do you use:
Describe your project (alternative: link to the project): Servant, hspec-discover, template-haskell, 1000 modules
Contents of
hie.yaml
:Steps to reproduce
Run haskell-language-server in that amazon linux docker container.
Expected behaviour
Actual behaviour
Include debug information
Execute in the root of your project the command
haskell-language-server --debug .
and paste the logs here:Not sure if I can post this.