Two instances of HLS started

[cptwunderlich]

In some cases, vscode-haskell starts two instances of HLS (consuming lots of memory).

There is a comment in my bug report on haskell-language-server which suggests, that this happens when opening a .hs file outside of the current project.

In this case, I did not do that - I was only working with files from my current project. I will attach the (quite large) HLS log file, hoping it will be of help. In a quick search I could not the files corresponding with the launch of the instance though. (This should happen closer to the end of the log file - I opened the task monitor after noticing my Laptop struggling and then closed VS Code)

hls-7.10.2021.log

Edit:

OS is Ubuntu Linux 20.04.3 LTS GHC version 8.10.4 VS Code 1.60.2 vscode-haskell 1.7.1

Working on GHC source

[jneira]

thanks, would be great to have a reproducible case, maybe we could analyze the opening of files out of the workspace, which seems to be reproducible

[Friede80]

I am experiencing this as well.

While I was playing around with it a bit, I noticed between some projects I wasn't always launching the same version of haskell-language-server. Looking at the extension options, I am confused about how the "Server Executable Path" option is supposed to behave. I can set the path at the User level or the Workspace level, but the option description say "Deprecated scope: This option will be set to machine scope in a future release, so it can be changed only globally, not per workspace."

Is "machine" scope set elsewhere? Is it possible that when opening a haskell file outside of my current workspace, it is picking up different options?

Also, I remembered that I am using the Nix Environment Selector extension to run within a nix-shell. Not sure if that is the culprit, but it seems worth noting.

Just a few thoughts for now. I will try and dig in later to provide some more concrete info.

[berberman]

This duplication seems to happen randomly for me, but I have no idea how to reproduce. @felixonmars reported this problem to me before, and maybe he could provide more useful information.

[cptwunderlich]

thanks, would be great to have a reproducible case, maybe we could analyze the field out of the workspace, which is reproducible

Yes, but unfortunately, it seems to happen randomly for me. Other users have suggested that it happens when opening files outside of the current cradle. I this case, I don't believe that's what happened.

Anyway, I'll keep an eye on it.

[jneira]

could it be related with the use of start/stop or restart commands?

[cptwunderlich]

In this case, I did not use those commands.

[jneira]

Is "machine" scope set elsewhere? Is it possible that when opening a haskell file outside of my current workspace, it is picking up different options?

It is not clear sorry. The scope is something you set when you define the variable in the extension and machine means the variable only can be set globally, no per workspace. The extension starts a server per workspace or file out of any workspace. But also there are workspaces with multiple folders and one server will be started for each folder see

https://github.com/haskell/vscode-haskell/blob/20204889fdc5ebde23c9d723b45e16fc49562035/src/extension.ts#L35-L39

[jneira]

thanks, would be great to have a reproducible case, maybe we could analyze the opening of files out of the workspace, which seems to be reproducible

that behaviour is described in #300

[soenkehahn]

I get two instances of HLS whenever I open a new (i.e. not previously existing) haskell module file. So let's say in a project that doesn't yet have a src/New.hs file, when I type code src/New.hs, vscode opens the new file and immediately spawns a second HLS process.

Do you need more info to reproduce this? I could put up an example project that shows this behavior, if that'd be helpful.

[fendor]

An example project would be immensely helpful, yes, please!

[soenkehahn]

UI issues can be tricky to reproduce, but here's my attempt:

• clone this repo: https://github.com/soenkehahn/two-hls-instances
• open the repo with vscode (e.g. with code -n .)
• make vscode trust the directory through the ui. This is needed for the vscode-haskell extension to run.
• close vscode
• run ./reproduce.sh from that directory

I hope that script is self-explanatory (here's a link). If not let me know.

I hope this helps. If you have problems reproducing the behavior with this, let me know. I may find more time to help.

I'm using: ubuntu 22.10 vscode 1.74.2 haskell.haskell@2.2.2 haskell-language-server 1.9.0.0 stack 2.9.3

[PaulJohnson]

It seems to happen when clicking on Go to Definition in the context menu. That opens up the target file using its absolute path name rather than the relative path name, which is probably significant.

Update

Yup, definitely matters. If you add the project folder starting from ~ then this bug manifests when you use Go to Definition to go to a file that isn't already open. But if you add the project folder by navigating from / then it works fine. Check the file breadcrumb at the top of the window to see where the editor thinks it is.

[runeksvendsen]

I'm hitting this issue. It happens when I have a bunch of files open the the VS Code instance that's running HLS. I don't have any Haskell files from other projects open, though.

Here's htop showing two HLS processes:

HLS log file (from VS Code "Output" tab): https://gist.github.com/runeksvendsen/836cf2f510102379ccb59f47dfc6f309

Notice the following errors:

2023-04-05T06:40:24.918031Z | Warning | Retrying hiedb action...
  delay: 1558
  maximum delay: 1000000
  retries remaining: 9
  SQLite error: SQLite3 returned ErrorBusy while attempting to perform step: database is locked

I suspect they happen because two HLS processes are trying to get a lock on the same SQLite DB.

[fendor]

UI issues can be tricky to reproduce, but here's my attempt:

Your example is reproducible but it is the correct behaviour, in my opinion, you opened a new file that does not belong to the current project, then we need to launch a new HLS instance, since we might need a different GHC version to compile the project. True, the process will linger, if you save the file and make it a part of the cabal project... but I don't know what else we could do in that situation?

However, your way of reproducing it gave me an idea, maybe when we switch branches, and we have files that no longer exist after switching... maybe that launches a new instance as well?

[Maurice-Byrne]

I think I'm encountering the same issue. With multiple instances of HLS being spawned for files that should all be within the same cabal project.

I think in this instance it seems to be symlinks causing it, as the notification comes up as setting up the project in one location while VS code claims to be open in another (same actual file, but the paths are different).

[soenkehahn]

Your example is reproducible but it is the correct behaviour, in my opinion, you opened a new file that does not belong to the current project, then we need to launch a new HLS instance, since we might need a different GHC version to compile the project.

@fendor: Why do you say it does not belong to the current project? At least it's my intention that it should. How does hls determine which files belong to a project and which don't?

[PaulJohnson]

Your example is reproducible but it is the correct behaviour, in my opinion, you opened a new file that does not belong to the current project, then we need to launch a new HLS instance, since we might need a different GHC version to compile the project.

No, you misunderstand, its the same file, just accessed via a different pathname. HLS sees /home/joe/MyProject, ~/MyProject and ~joe/MyProject as three different paths, even though they all resolve to the same place.

Presumably HLS needs to canonicalise the paths it gets before checking them against the project.

[fendor]

Ah, I see, I think you are correct, we don't handle the workspaces correctly.

[hasufell]

Presumably HLS needs to canonicalise the paths it gets before checking them against the project.

Does not work with bind mounts.