HLS stuck (init then no progress) since multi home support #4046
Comments
guibou
added
type: bug
|
I think @wz1000 is our best bet for guessing what's going on. |
|
I would add more traces in Session.hs to figure out exactly where it gets stuck. |
|
@wz1000 I will do that, thank you for the filename, it helps me a lot. |
|
I've added a bunch of debug log statment in In let targetEnv = (if isBad ci then multi_errs else [], Just henv)
targetDepends = componentDependencyInfo ci
res = ( targetEnv, targetDepends)
liftIO $ logWith recorder Logger.Debug $ LogDLLLoadError "Foo"
logWith recorder Debug $ LogNewComponentCache res
liftIO $ logWith recorder Logger.Debug $ LogDLLLoadError "Bar"
evaluate $ liftRnf rwhnf $ componentTargets ci
Actually, if I even replace the |
|
The tuple in |
- let targetEnv = (if isBad ci then multi_errs else [], Just henv)
+ let targetEnv = ([], Just henv)Completely unlocks my HLS, and I even have diagnostics. I'll apply this as a patch at work in order to progress forward. I can investigate a bit more if you give me some guidance. edit |
|
Okay, so that does seem like it shouldn't get stuck. Do we have a test case for that? It looks like it's specifically for things that violate the closure property. Obviously we should also give an error, but it looks like we get stuck in the process of trying to work out the error 😂 |
|
Maybe |
|
Yeah this might be a GHC bug. Can you print out |
|
Alternatively, looking at the comment on https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/Driver/Make.hs#L1756, perhaps it just has bad complexity and so since you have a massive package db it's just doing some quadratic or otherwise huge amount of work? |
|
Also printing out the |
We are affected by haskell/haskell-language-server#4046 and this makes hls 2.6.0.0 not block on our codebase.
We are affected by haskell/haskell-language-server#4046 and this makes hls 2.6.0.0 not block on our codebase.
|
@wz1000, sorry, I'm taking too much time to answer. Apparently I'm not the only one with this issue, so my "weird" setup with nix may not be responsible.
for Recall that I'm not using "home unit" yet and my build is only composed of
An infinite loop is hidden in |
|
Note, a few line above, the call |
you want to use |
|
Some news. Removing the |
…ts in the project. GHC gives a default "main" home unit, and it is difficult to avoid this as each ghc session must have an active home unit at all times, but in a multiple component session, there is no other good choice for a default unit. We could pick one arbitrarily, but this is ugly and complicates the code a lot. We never use this default "main" unit for anything, as the GHC sessions corresponding to any file/component have the active unit set to the correct one for that component. When checking for home unit closure, we must make sure to include only the actual units in the project, not the bogus "main" unit that GHC forces us to have. Including the main unit seems to make the `checkHomeUnitsClosed` loop forever for some reason. Fixes #4046
|
Thanks @carbolymer, thanks to your reproducer I was able to diagnose the issue and put up a fix in #4109 |
|
Thank you @carbolymer, and thank you @wz1000! |
GHC had an implementation of this function, but it was horribly inefficient We should move back to the GHC implementation on compilers where https://gitlab.haskell.org/ghc/ghc/-/merge_requests/12162 is included Fixes #4046
GHC had an implementation of this function, but it was horribly inefficient We should move back to the GHC implementation on compilers where https://gitlab.haskell.org/ghc/ghc/-/merge_requests/12162 is included Fixes #4046
fendor
added
multi-component
GHC had an implementation of this function, but it was horribly inefficient We should move back to the GHC implementation on compilers where https://gitlab.haskell.org/ghc/ghc/-/merge_requests/12162 is included Fixes #4046
GHC had an implementation of this function, but it was horribly inefficient We should move back to the GHC implementation on compilers where https://gitlab.haskell.org/ghc/ghc/-/merge_requests/12162 is included Fixes #4046
* Use a faster implementation of checkHomeUnitsClosed GHC had an implementation of this function, but it was horribly inefficient We should move back to the GHC implementation on compilers where https://gitlab.haskell.org/ghc/ghc/-/merge_requests/12162 is included Fixes #4046 * Update ghcide/src/Development/IDE/GHC/Compat/Core.hs Co-authored-by: Jan Hrcek <2716069+jhrcek@users.noreply.github.com> * Update ghcide/session-loader/Development/IDE/Session.hs Co-authored-by: Jan Hrcek <2716069+jhrcek@users.noreply.github.com> * Follow guidelines --------- Co-authored-by: Jan Hrcek <2716069+jhrcek@users.noreply.github.com>
First, I apologize for the lack of reproducibility in this issue. I'm a bit lost here and I need your help. I'll try to gather as much information as possible, but for now I don't have much.
Since we upgraded at work HLS from 2.4.0.0 to 2.6.0.0, HLS is "stuck" on some (but not all) of our projects.
By stuck, I mean that HLS starts, gather information for the build flags thank to our
hie.yaml/cradle:bios:shellcommand, and then nothing else is happening. CPU runs at 100% (of one core) and the latest entry in the log is:Your environment
We are using Linux. I'm debuging that on NixOS, but users had observed the same problem on Ubuntu.
GHC 9.6.4 (But same problem with 9.8.1), installed from nixpkgs. HLS is installed from nixpkgs too.
The project is built with a custom build system using nix and we use a
cradle:bios:shellcommand to output the build flags. Note that the command works fine, so HLS is not blocked on this.A few notes about our build system.
Our build system is based on nix, but that's orthogonal to our problem (I think) because mostly what it does is populating the environment with the correct version of GHC and providing flags for HLS.
Note that we have one specifitity which may be responsible for the problem. We have a "main project" and multiples subprojects.
ghc-pkg checkonly warns about missinghaddockentries. None of our subproject work correctly with HLS, they are all stuck.HLS bisect
I've bisected HLS (starting on tag
2.6.0.0and2.4.0.0as "bad" and "good" and I hit:As the possibly offending commit.
Note that we are not using the multi unit argument syntax in our project, but next step (after having a look in diagonal on this commit to see if I can see something which could lead to the "live lock") will be to try to convert our codebase to the multi unit syntax.
Steps to reproduce
No simple reproducer yet, sorry. The main codebase is private and includes client IP that we cannot unfortunately share easilly. I'm working on making a simpler reproducer.
Expected behaviour
Actual behaviour
Debug information
Here is the content of the log, using
--debug --log ...:(some name had been replaced by
fooorbarbecause that's a private "client" project)our HIE_BIOS file is like:
Note that if I remove the
-package-dbargument (and all the-package-idwhich are not in a "default" package db), HLS starts immediatly and perfectly works (and fails because most of myimportcannot be resolved). I tried to remove the-package-idonly and keep the-package-db, and then HLS is stuck again. So definitiely, there may be something in my package db which blocks HLS.The text was updated successfully, but these errors were encountered: