HIE hangs with 100% on one CPU core VSCode/Nix

gcharnock commented 5 years ago

I've got a project that seemed to be working with VSCode/HIE and building under nix. I made some changes and HIE stopped responding and used 100% of one cpu core. I tried attaching with strace and got the following output:

strace -p $PID
strace: Process $PID attached
futex(0x6b3d748, FUTEX_WAIT_PRIVATE, 0, NULL

So it looks like the process is not doing any IO; I'm assuming it's stuck in a loop.

The slightly bizarre thing is if I revert those changes, the problem persists. Would like to try making a minimal example project that reproduces the bug, but at the moment I'm not sure how to get hie back. I've tried deleting the ./dist folder that cabal creates. What places does hie keep state that I could try getting rid of?

details I am using the following as my hie-wrapper:

nix-shell --command "hie-wrapper --lsp -d -l /tmp/hie.log --vomit"

The produced log file is: hie.log

I'm using the hie from commit 96af698f0cfefdb4c3375fc199374856b88978dc of the nix repo.

lukel97 commented 5 years ago

What places does hie keep state that I could try getting rid of?

hie doesn't store any state itself, but often times deleting the dist/new-dist/.stack-work folders can help

lukel97 commented 5 years ago

2018-10-04 13:30:24.832292913 [ThreadId 13] - ghcDispatcher:Processing request as version matches
2018-10-04 13:30:24.832556964 [ThreadId 13] - setTypecheckedModule: file mapping state is: fromList [("/home/gareth/dev/inotify-tool/src/Main.hs",FileMapping {fmPath = "/run/user/1000/ghc-mod1894/Main1893-0.hs", fmTemp = True})]
2018-10-04 13:30:24.832619519 [ThreadId 13] - setTypecheckedModule: before ghc-mod

Judging from the logs, it looks like hie hasn't heard back from ghc-mod when it's trying to typecheck the module. Is the project large? If it hasn't been built before then sometimes hie can hang trying to build it first. If you build it first with cabal build/stack build and then retry it with hie do you still get the same hanging?

gcharnock commented 5 years ago

The project isn't large, one Main.hs file. I also may have miss-characterized the nature of the problem as being stateful when it wasn't. What I think is happening is that hie goes into a 100% CPU loop and will remain there if I don't touch anything, but it sometimes seems to recover if I continue editing the files in the project. The 100% CPU usage remains, but I start getting type errors being reported again.

If I can find myself some free time, I will try and get a minimal example. That might not be for a while though.

Thank you for the response.

jflanglois commented 5 years ago

For a specific example, I've experienced this behavior on https://github.com/lucasdicioccio/warp-grpc-example.

sboehler commented 5 years ago

I seem to encounter the same behavior. Whenever I launch emacs from within the nix-shell, HIE seems to max out one core for up to two minutes on my system, before eventually responding and becoming functional. I am using the cabal new-build commands, but switching to the old version makes no difference.

Steps to reproduce:

clone https://github.com/sboehler/freer-servant/tree/20e24fbe6d7eb14284b84c3316bcd55ec49d530e
enter the nix-shell (provides HIE via @domenkozar 's excellent hie-nix repository.
launch emacs
trigger HIE, for example by asking lsp-find-definition on some identifier.
observe 100% load for an extended period of time until HIE starts reacting
once CPU usage falls to zero, HIE works perfectly

Relevant extract from my emacs config:

  (use-package lsp-mode
    :ensure t
    :commands lsp
    :bind (:map lsp-mode-map
                ("C-c f" . lsp-format-buffer)
                ("C-c h" . lsp-describe-thing-at-point))
    :hook ((typescript-mode haskell-mode typescript-tsx-mode) . lsp)
    :init
    (setq lsp-prefer-flymake nil))
  (use-package lsp-ui
    :ensure t
    :commands lsp-ui-mode
    :bind  (:map lsp-mode-map
                 ("C-c /" . lsp-ui-sideline-apply-code-actions)
                 ("C-c ?" . lsp-ui-peek-find-references)
                 ("C-c d" . lsp-ui-peek-find-definitions)))
  (use-package company-lsp :commands company-lsp)
  (use-package haskell-mode
    :hook (haskell-mode . (lambda ()
                            (interactive-haskell-mode)
                            (setq tab-width 2
                                  haskell-interactive-popup-errors nil))))
  (use-package lsp-haskell :ensure t)

alanz commented 5 years ago

Try doing a stack build on the command line before launching hie, and see if it still maxes the CPU. I suspect what you are seeing is a delay while hie invokes stack to build the project initially. We need to improve the user feedback in this scenario.

garry-cairns commented 5 years ago

I'm also experiencing something similar, but I don't use stack at all:

Description

I installed hie84 today for integrating with emacs. I got everything running and connected to the LSP server. At that point my fans started going full-tilt and top showed GHC using > 400% CPU. I had to kill GHC twice to get everything to calm down. EDIT: after reading this thread I tried letting it run for a while and it does indeed calm down to a functional experience.

Steps to reproduce

I'm not sure which parts of my nixos config will be relevant so I'm linking to it all. Essentially I installed as per the instructions in the README for nix and encountered the problem immediately.

Ancillary questions

I seem unable to uninstall hie84 with nix-env -e, so I'd be keen to know how to do so since editing Haskell files is somewhat unpleasant.

fendor commented 5 years ago

Does it happen every time you open it? I installed hie vie via hie-nix and the command nix-env -f default.nix -i hies

Normally, hie has to configure/build the project once. So, while it is true that the cpu maxes out, it has to do this in order to function. However, only once not every time you open your project.

Uninstall With nix-env -qa you should be able to see the installed packages by name. Is it listed there?

garry-cairns commented 5 years ago

@fendor you're correct that it seems to be a one-time cost so I'll keep it around. -q showed why the uninstall wasn't working — it's called haskell-ide-engine rather than hie84 once installed.

fendor commented 5 years ago

Great, then this is not really a bug, the feedback must be improved, though.

domenkozar commented 5 years ago

There was a serious regression found in Nix GHC setup, I'm currently compiling hie-nix that should fix it - worth a try: https://github.com/domenkozar/hie-nix/issues/59

mpickering commented 5 years ago

@domenkozar I don't think using a new version of hie-nix will help this problem.

freuk commented 5 years ago

The issue was also observed on this repository. I'm entering a nix-shell and running cabal update && cabal configure && cabal build && rm -rf ~/.cache/cabal-helper, then starting HIE through hie-wrapper -d. The first invocation hangs for a minute on parallelized ghc calls, and HIE works fine afterwards. Thanks!

edit: On the off chance that this has to do with nix/cabal-specific issues: https://github.com/Infinisil/all-hies/issues/12

haskell / haskell-ide-engine