Frequent crashes loading Hasktorch

[tscholak]

This problem is new for me. I just finished updating my Hasktorch dev environment by bumping the version of ghc to 8.10.4. Before I was using hls 0.7 with Hasktorch, now I've tried both 0.9 and 1.0, but both are suddenly very unstable.

Your environment

Output of haskell-language-server --probe-tools or haskell-language-server-wrapper --probe-tools:

haskell-language-server version: 1.0.0.0 (GHC: 8.10.4) (PATH: /nix/store/wsrhqfn07rif6n27qglc3p68kjaflyax-haskell-language-server-exe-haskell-language-server-1.0.0.0/bin/haskell-language-server)
Tool versions found on the $PATH
cabal:		3.2.0.0
stack:		2.5.1
ghc:		8.10.4

Which lsp-client do you use:
vs code

Describe your project (alternative: link to the project):
https://github.com/hasktorch/hasktorch/blob/master/cabal.project

Contents of hie.yaml:
https://github.com/hasktorch/hasktorch/blob/master/hie.yaml

Steps to reproduce

start vscode from nix shell, work for a few seconds on random things, crash occurs

Expected behaviour

no crash

Actual behaviour

crash

Include debug information

Execute in the root of your project the command haskell-language-server --debug . and paste the logs here:

Debug output:

the full output is too long to post here. it finishes after a while with:

Completed (36 files worked, 298 files failed)

Paste the logs from the lsp-client, e.g. for VS Code

LSP logs:

likewise, this log is too long. I'll upload a file...

[konn]

I encountered this issue several times in a closed in-house codebase (without deps to Hasktorch), although I couldn't make minimal repro.
Telling from situational evidence in our project, it seems that modules with type-checker plugins can make HLS 1.0 crash, but not always. There is no concrete evidence though.

EDIT: We use ghc-typelits-natnormalise, ghc-typelits-presburger-knownnat and ghc-typelits-presburger in our code base, where the first two are common with hasktorch. Our crashing modules use -natnormalise and -presburger simultaneously.

[tscholak]

Thanks for these pointers.
It would be a surprise to me, though. Have hls 0.9 and 1.0 become less stable under the presence of these plugins? I'm a longtime user of hls with hasktorch, and with 0.7 and ghc 8.10.3 I did not have such severe stability problems.

[wz1000]

GHC 8.10.4 had some changes to the linker which might be responsible. Maybe you could try going back to 8.10.3 with HLS 1.0?

[tscholak]

let me try that @wz1000!

[wz1000]

It seems like its segfaulting with GHC 8.10.4, but I can't manage to get a proper backtrace.

[tscholak]

at least I know now that I'm not crazy and alone with this issue. did you use the nix environment? stack? cabal?

[wz1000]

I used cabal.

The segfault happens non-deterministically after editing for a few minutes. I can't figure out how to consistently reproduce it. My guess it that some code is not exception safe, probably in a plugin. ghcide uses async exceptions to cancel old compiles when the file is modified.

[tscholak]

type checker plugin or hls plugin?

[wz1000]

I meant type checker plugin, but I'm doubting this hypothesis since an uninterruptibleMask_ around the typechecking code didn't seem to help.

The problem is not with a HLS plugin because I can reproduce it with plain ghcide.

On my last attempt, ghcide printed out ghcide: munmap: Invalid argument before dying.

[wz1000]

I think the root cause is this ghc issue: https://gitlab.haskell.org/ghc/ghc/-/issues/19417

[wz1000]

With the debug RTS, ghcide crashes with ghcide: internal error: ASSERTION FAILED: file rts/CheckUnload.c, line 457