HLS crashes with "The Haskell (<proj>) server crashed 5 times in the last 3 minutes. The server will not be restarted." #1342
Comments
jneira
added
os: macos
type: bug
|
Thanks Javier. I don't have have haskell-language-server on my path (was downloaded by the VSCode extension and presumably cached somewhere). If you'd like me to run I've attached the log file generated by setting a file into the VSCode extension settings. |
|
Thanks, the vscode log would be enough to confirm it is not a duplicate of #230. At least the compiler panic is not present. To try to workraround the issue and find the possible cause we can disable all plugins and reenable it one by one. {
"haskell": {
"plugin" : {
"importLens" : {
"globalOn" : false
},
"hlint" : {
"globalOn" : false
},
"eval" : {
"globalOn" : false
},
"moduleName" : {
"globalOn" : false
},
"splice" : {
"globalOn" : false
},
"haddockComments" : {
"globalOn" : false
},
"class" : {
"globalOn" : false
},
"retrie" : {
"globalOn" : false
},
"tactic" : {
"globalOn" : false
},
"pragmas" : {
"globalOn" : false
}
}
}
}... and test if the crash is reproduced |
jneira
added
status: needs info
|
Added the settings file and restarted vscode. I have attached the log from that run, where you can see the settings reproduced, but the vscode extension still crashes in a loop. |
|
@levans thanks for trying it, from the log we can deduce that the configuration is in effect, cause the specific log for plugins is not included anymore. And as all plugins are disabled the component causing the crash is probably ghcide. |
jneira
added
component: ghcide
and removed
status: needs info
|
Is there some template haskell used in the module? Iirc yesod make heavy use of th so probably that will be the case. |
|
Indeed Yesod makes a good deal of use of TH and quasiquotation for a number of embedded languages (HTML, CSS, data definition). The scaffold creates a range of modules with various examples of these. |
|
I have had a similar situation on macOS with VSCodium when I include Template Haskell through the optics or lens libraries. |
|
I have a similar situation where whenever I open a haskell project in VSC I get a message from the haskell extension saying |
|
I suspect I'm also encountering this bug; Mojave data NumericLit a where
NaturalLit :: NumericLit Natural
IntegerLit :: NumericLit Integer
DoubleLit :: NumericLit Double
deriveGEq ''NumericLit
data ComponentSpec a where
NumericLit :: NumericLit a -> ComponentSpec a
BoolLit :: ComponentSpec Bool
TextLit :: ComponentSpec Text
-- deriveGEq ''ComponentSpec -- Uncomment and go boom |
|
FWIW, I just relaunched VSCode to pick up 1.0.0 and immediately after the automatic update, the project seemed to be working fine. However, as soon as I relaunched VSCode I was back to the same behaviour. So, there's perhaps some difference in what happens during/post update vs the full reset when starting up normally. |
|
I've also had this and #1297 occur on my Nix-based development environment, I haven't tried reproducing it on a smaller, TH-less project yet though, but using a standard |
|
I'm running into the same issue using |
|
Is this the same issue as #1297 ? Seems very similar if not identical |
It's possible that you probably also hit the same issue we did with a mix of postgresql/TH in #1982 (comment) |
|
I'm still getting this problem (server crash) or some of my Macs. Could not track the cause. Everything's the latest released. All I can say that the workaround of starting VSC manually via |
For your specific case if it works from the terminal, usually means VSCode isn't populating your path correctly. Can you paste your logs when you see the error? |
The thought did cross my mind. I wonder how I can alleviate this problem of path not being populated properly (this is MacOS)...?
Sure. Which of the logs you think would help? For example: |
|
I forget where VS Code assigns the path. It doesn't use the same environment as a login shell. There should be a fix floating out around there. Based on the logs here it looks like GHC can't be found. To see the logs from HLS try either |
|
It turned out the problem was a command in On Mac, it takes forever (10-20 seconds, at least). Once I commented that line out (how could I miss it before?), another error disappeared - and PATH got the correct values in it. HLS no longer crashes. Thank you! |
|
This happened to me today, apparently I no longer had the correct version of the language language server installed for my version of ghc? |
Your environment
HLS 0.9.0
Running in a stack project sandbox
Hardware is a MacBookPro (2019) with macOS 11.2
Which lsp-client do you use: VSCode (HLS 0.9.0 is automatically downloaded by
Describe your project (alternative: link to the project):
Fails with all my yesod projects, and the basic scaffold project generated with:
stack new nasty yesodweb/postgresSteps to reproduce
stack new nasty yesodweb/postgresHopefully, this is easy to reproduce, given that the entire project can easily be generated from scaffold.
However, I will attempt to narrow the conditions by stripping the project further and will post and insights as addendums.
Expected behaviour
Expected that the metadata would be built successfully and session could continue as normal
Actual behaviour
"Processing" status line message shows stepping though files but resets several times until the final failure notification is displayed and the extension is disabled due to restarts.
Include debug information
Execute in the root of your project the command
haskell-language-server --debug .and paste the logs here:Debug output:
Paste the logs from the lsp-client, e.g. for VS Code
LSP logs:
The text was updated successfully, but these errors were encountered: