Skip to content
This repository was archived by the owner on Oct 7, 2020. It is now read-only.

HIE doesn't work with 'simple' yesod project #1207

Closed
skress opened this issue Apr 25, 2019 · 16 comments
Closed

HIE doesn't work with 'simple' yesod project #1207

skress opened this issue Apr 25, 2019 · 16 comments
Labels
os: macOS

Comments

@skress
Copy link
Contributor

skress commented Apr 25, 2019

Hi,

I am trying to use HIE with the current VSCode extension. HIE is started, then it dies after a couple of seconds. VSCode retries 5 times and then gives up.

The project is created via

stack new yesod-test yesod-sqlite

I can run successfully run stack build in the project, but due to bugs in GHC and the chosen LTS I cannot run stack haddock.

So I updated to LTS 13.17 which uses GHC 8.6.4 and I cherry picked https://gitlab.haskell.org/ghc/ghc/merge_requests/276/commits which fixes the GHC bug that prevents haddock from running successfully. With my fixed GHC I can now run stack haddock and stack hoogle. Nevertheless the result is the same: hie dies 5 times and then the extension doesn't try anymore.

For completeness: when upgrading to LTS 13.17 I needed to upgrade a couple of the dependencies and I needed to add haskell-src-exts-1.21.0@sha256:02421cacaa48c055551b8e5796efc543301b7ea9527a38e1385403d2b85512fb as extra-dependency to the project's stack.yaml.

This is the log output in VSCode:

info: Found Stack project at: /Users/skress/tmp/yesod-test
Using hie version: Version 0.8.0.0 (2579 commits) x86_64 ghc-8.6.4
info: Using Stack project at: /Users/skress/tmp/yesod-test
Using hoogle db at: /Users/skress/.hoogle/default-haskell-5.0.17.hoo
info: Found Stack project at: /Users/skress/tmp/yesod-test
info: Using Stack project at: /Users/skress/tmp/yesod-test
DEBUG: regenerating cache: /Users/skress/tmp/yesod-test/.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/setup-config.ghc-mod.cabal-components (cache missing or unreadable)
DEBUG: writing memory cache: /Users/skress/tmp/yesod-test/.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/setup-config.ghc-mod.cabal-components
DEBUG: resolveEntrypoint:
       ["-i","-i.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build","-isrc","-i.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/autogen","-i.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/global-autogen","-I.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/autogen","-I.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/global-autogen","-I.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build","-optP-include","-optP.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/autogen/cabal_macros.h"]
DEBUG: resolveEntrypoint:
       ["-i","-i.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/yesod-test/yesod-test-tmp","-iapp","-i.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/yesod-test/autogen","-i.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/global-autogen","-I.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/yesod-test/autogen","-I.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/global-autogen","-I.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/yesod-test/yesod-test-tmp","-optP-include","-optP.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/yesod-test/autogen/cabal_macros.h"]
DEBUG: resolveEntrypoint: []
DEBUG: making sure autogen files exist
DEBUG: resolvedComponentsCache: files changed: none
DEBUG: resolveGmComponent:
       ["-optP-include","-optP.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/autogen/cabal_macros.h"]
DEBUG: resolveGmComponent:
       ["-i","-i.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/yesod-test/yesod-test-tmp","-iapp","-i.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/yesod-test/autogen","-i.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/global-autogen","-I.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/yesod-test/autogen","-I.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/global-autogen","-I.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/yesod-test/yesod-test-tmp","-optP-include","-optP.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/yesod-test/autogen/cabal_macros.h","-XHaskell2010","-optP-include","-optP.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/autogen/cabal_macros.h"]
DEBUG: resolveGmComponent:
       ["-i","-i.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build","-isrc","-i.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/autogen","-i.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/global-autogen","-I.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/autogen","-I.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/global-autogen","-I.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build","-optP-include","-optP.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/autogen/cabal_macros.h","-XHaskell2010","-optP-include","-optP.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/autogen/cabal_macros.h"]
DEBUG: regenerating cache: .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/setup-config.ghc-mod.resolved-components (cache missing or unreadable)
DEBUG: writing memory cache: .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/setup-config.ghc-mod.resolved-components
VOMIT: hide all packages(ignore .ghc.environment):: DontLoadGhcEnvironment
VOMIT: Using the following mapped files: "/Users/skress/tmp/yesod-test/src/Application.hs"
VOMIT: Using the following mapped files: "/Users/skress/tmp/yesod-test/src/Application.hs"
VOMIT: Initializing GHC session with following options: "-fbuilding-cabal-package" "-O" "-outputdir" ".stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build" "-odir" ".stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build" "-hidir" ".stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build" "-stubdir" ".stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build" "-i" "-i.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build" "-isrc" "-i.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/autogen" "-i.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/global-autogen" "-I.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/autogen" "-I.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/global-autogen" "-I.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build" "-optP-include" "-optP.stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/autogen/cabal_macros.h" "-this-unit-id" "yesod-test-0.0.0-6DjXNe20DleW7CMppajBn" "-hide-all-packages" "-Wmissing-home-modules" "-no-user-package-db" "-package-db" "/Users/skress/.stack/snapshots/x86_64-osx/lts-13.17/8.6.4/pkgdb" "-package-db" "/Users/skress/tmp/yesod-test/.stack-work/install/x86_64-osx/lts-13.17/8.6.4/pkgdb" "-package-id" "aeson-1.4.2.0-9cSxVTttZ9O9gQQeYMFLor" "-package-id" "base-4.12.0.0" "-package-id" "bytestring-0.10.8.2" "-package-id" "case-insensitive-1.2.0.11-GGYU9CY9cs88wywgwHVKC6" "-package-id" "classy-prelude-1.5.0-9ua77cq6KAUIhfNv7qqpNw" "-package-id" "classy-prelude-conduit-1.5.0-E7fRBtKKtGQ8ttlUwXVnpL" "-package-id" "classy-prelude-yesod-1.5.0-1TnZAq8ZUafHCtlvaf8Ok0" "-package-id" "conduit-1.3.1.1-9dJdFSy5i9yEMUCfUtIeMw" "-package-id" "containers-0.6.0.1" "-package-id" "data-default-0.7.1.1-48AlmAL5bp0K1GegiZac8Q" "-package-id" "directory-1.3.3.0" "-package-id" "fast-logger-2.4.15-5ogIBC4IeSf8znicURd5U9" "-package-id" "file-embed-0.0.11-4IE3sw0bCLQ7xXwEGMUYke" "-package-id" "foreign-store-0.2-FCKu23zJ1MhKEqdHalRzFz" "-package-id" "hjsmin-0.2.0.2-7ujCE5A9usgHO0U0zlM90P" "-package-id" "http-client-tls-0.3.5.3-4Oj3XfLIB1u1YcwkJvsJyQ" "-package-id" "http-conduit-2.3.7-7GcjDE8EjpuB5TglywFQE3" "-package-id" "monad-control-1.0.2.3-MU9UBTCjrb6B3h9cgBZmE" "-package-id" "monad-logger-0.3.30-GEWCAHrLi3C16XdkA2qgQQ" "-package-id" "persistent-2.9.2-8ZsEOLdPGVyMpKk9TbNm6" "-package-id" "persistent-sqlite-2.9.3-GCcpwQxiUmBKqTffmjVCC" "-package-id" "persistent-template-2.5.4-1p3PyRQtkwjA8WlmYjgfLg" "-package-id" "safe-0.3.17-43oyx4B630gDZMbTh3Ttji" "-package-id" "shakespeare-2.0.20-GgZsrpU3qRD7IcOFzA7qLZ" "-package-id" "template-haskell-2.14.0.0" "-package-id" "text-1.2.3.1" "-package-id" "time-1.8.0.2" "-package-id" "unordered-containers-0.2.9.0-BRWkoSTuML1cQdpep6Oin" "-package-id" "vector-0.12.0.2-AoZ9EwUsgIW1yrOc105QXH" "-package-id" "wai-3.2.2-ItOaIlhStjHFO5Ka82Wde" "-package-id" "wai-extra-3.0.25-DZTrSe3T9l0HrwTFrBnu0y" "-package-id" "wai-logger-2.3.4-5sEZlyZhmcYAw79Hj8qvs" "-package-id" "warp-3.2.26-AFIGCLCiaz23mDsL3PYZV1" "-package-id" "yaml-0.11.0.0-KC6yhv4lzea9KrxGHmNBH5" "-package-id" "yesod-1.6.0-2EAJfcvA8rgCwtAJe48cVL" "-package-id" "yesod-auth-1.6.6-5h65fgi6e2A95CrbtzJi7j" "-package-id" "yesod-core-1.6.14-NXRwhm3esn34tB0knb3g1" "-package-id" "yesod-form-1.6.4-Jf50ecrTMQwLDv7EbLXrL6" "-package-id" "yesod-static-1.6.0.1-6AcQgmxsoY1G9JLY1pgT7q" "-XHaskell2010" "-Wall" "-fwarn-tabs" "-O2" "-Wno-missing-home-modules" "-O0" "-fno-warn-missing-home-modules" "-Wwarn"
DEBUG: initSession: Session not initialized, creating new one
VOMIT: Using the following targets: "/Users/skress/tmp/yesod-test/src/Application.hs" "/Users/skress/tmp/yesod-test/src/Application.hs"
DEBUG: loadTargets:
       Loading: /private/var/folders/rx/6cf2s8fd33z4pt3xm_lkgrsc0000gn/T/ghc-mod42844/Application42843-0.hs
DEBUG: loadTargets: filterModSums: True
info: loadTargets:
      Target needs interpeter, switching to LinkInMemory/HscInterpreted. Perfectly normal if anything is using TemplateHaskell, QuasiQuotes or PatternSynonyms.
hie-wrapper: callProcess: /Users/skress/.local/bin/hie-8.6.4 "--lsp" "-d" "-l" "/var/folders/rx/6cf2s8fd33z4pt3xm_lkgrsc0000gn/T/hie.log" "--vomit" (exit -11): failed
[Info  - 12:36:26 PM] Connection to server got closed. Server will restart.

This is part of the debug output of hie:

2019-04-25 12:36:20.021277 [ThreadId 4] - run entered for hie-wrapper(hie-wrapper) Version 0.8.0.0 (2579 commits) x86_64 ghc-8.6.4
2019-04-25 12:36:20.022045 [ThreadId 4] - Current directory:/Users/skress/tmp/yesod-test
2019-04-25 12:36:20.501057 [ThreadId 4] - Cradle directory:/Users/skress/tmp/yesod-test
2019-04-25 12:36:20.501527 [ThreadId 4] - Using stack GHC version
2019-04-25 12:36:20.934247 [ThreadId 4] - Project GHC version:8.6.4
2019-04-25 12:36:20.934341 [ThreadId 4] - hie exe candidates :["hie-8.6.4","hie-8.6","hie"]
2019-04-25 12:36:20.934593 [ThreadId 4] - found hie exe at:/Users/skress/.local/bin/hie-8.6.4
2019-04-25 12:36:20.934635 [ThreadId 4] - args:["--lsp","-d","-l","/var/folders/rx/6cf2s8fd33z4pt3xm_lkgrsc0000gn/T/hie.log","--vomit"]
2019-04-25 12:36:20.93466 [ThreadId 4] - launching ....



2019-04-25 12:36:20.951212 [ThreadId 4] - Using stack GHC version
2019-04-25 12:36:21.379566 [ThreadId 4] - Run entered for HIE(hie-8.6.4) Version 0.8.0.0 (2579 commits) x86_64 ghc-8.6.4
2019-04-25 12:36:21.379686 [ThreadId 4] - Current directory:/Users/skress/tmp/yesod-test
2019-04-25 12:36:21.379716 [ThreadId 4] - Enabling --vomit for ghc-mod. Output will be on stderr
2019-04-25 12:36:21.37977 [ThreadId 4] -




haskell-lsp:Starting up server ...
2019-04-25 12:36:21.379976 [ThreadId 4] - ---> {"jsonrpc":"2.0","id":0,"method":"initialize","params":{"processId":42805,"rootPath":"/Users/skress/tmp/yesod-test","rootUri":"file:///Users/skress/tmp/yesod-test","capabilities":{"workspace":{"applyEdit":true,"workspaceEdit":{"documentChanges"
:true},"didChangeConfiguration":{"dynamicRegistration":true},"didChangeWatchedFiles":{"dynamicRegistration":true},"symbol":{"dynamicRegistration":true,"symbolKind":{"valueSet":[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26]}},"executeCommand":{"dynamicRegistration":tr
ue},"configuration":true,"workspaceFolders":true},"textDocument":{"publishDiagnostics":{"relatedInformation":true},"synchronization":{"dynamicRegistration":true,"willSave":true,"willSaveWaitUntil":true,"didSave":true},"completion":{"dynamicRegistration":true,"contextSupport":true,"completionItem":{"snippetSupport":true,"commitCharactersSupport":true,"documentationFormat":["markdown","plaintext"],"deprecatedSupport":true,"preselectSupport":true},"completionItemKind":{"valueSet":[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25]}},"hover":{"dynamicRegistration":true,"contentFormat":["markdown","plaintext"]},"signatureHelp":{"dynamicRegistration":true,"signatureInformation":{"documentationFormat":["markdown","plaintext"]}},"definition":{"dynamicRegistration":true},"references":{"dynamicRegistration":true},"documentHighlight":{"dynamicRegistration":true},"documentSymbol":{"dynamicRegistration":true,"symbolKind":{"valueSet":[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26]},"hierarchicalDocumentSymbolSupport":true},"codeAction":{"dynamicRegistration":true,"codeActionLiteralSupport":{"codeActionKind":{"valueSet":["","quickfix","refactor","refactor.extract","refactor.inline","refactor.rewrite","source","source.organizeImports"]}}},"codeLens":{"dynamicRegistration":true},"formatting":{"dynamicRegistration":true},"rangeFormatting":{"dynamicRegistration":true},"onTypeFormatting":{"dynamicRegistration":true},"rename":{"dynamicRegistration":true},"documentLink":{"dynamicRegistration":true},"typeDefinition":{"dynamicRegistration":true},"implementation":{"dynamicRegistration":true},"colorProvider":{"dynamicRegistration":true},"foldingRange":{"dynamicRegistration":true,"rangeLimit":5000,"lineFoldingOnly":true}}},"trace":"off","workspaceFolders":[{"uri":"file:///Users/skress/tmp/yesod-test","name":"yesod-test"}]}}
2019-04-25 12:36:21.38096 [ThreadId 4] - haskell-lsp:initializeRequestHandler: setting current dir to project root:/Users/skress/tmp/yesod-test
2019-04-25 12:36:21.381375 [ThreadId 10] - ****** reactor: top of loop
...

... and these are the last lines of the output:

2019-04-25 12:36:46.853527 [ThreadId 10] - ****** reactor: got message number:4
2019-04-25 12:36:46.85359 [ThreadId 10] - reactor:got CodeActionRequest:RequestMessage {_jsonrpc = "2.0", _id = IdInt 2, _method = TextDocumentCodeAction, _params = CodeActionParams {_textDocument = TextDocumentIdentifier {_uri = Uri {getUri = "file:///Users/skress/tmp/yesod-test/src/Application.hs"}}, _range = Range {_start = Position {_line = 42, _character = 18}, _end = Position {_line = 42, _character = 18}}, _context = CodeActionContext {_diagnostics = List [], only = Nothing}}}
2019-04-25 12:36:46.853644 [ThreadId 10] - ****** reactor: top of loop
2019-04-25 12:36:46.853669 [ThreadId 13] - ideDispatcher: got request 4 with id: IdInt 2
2019-04-25 12:36:46.853697 [ThreadId 13] - ideDispatcher: top of loop
2019-04-25 12:36:46.853717 [ThreadId 13] - ideDispatcher: got request 4 with id: IdInt 2
2019-04-25 12:36:46.85374 [ThreadId 13] - ideDispatcher: top of loop
2019-04-25 12:36:46.853758 [ThreadId 13] - ideDispatcher: got request 4 with id: IdInt 2
2019-04-25 12:36:46.853779 [ThreadId 13] - ideDispatcher: top of loop
2019-04-25 12:36:46.8538 [ThreadId 13] - ideDispatcher: got request 4 with id: IdInt 2
2019-04-25 12:36:46.853915 [ThreadId 13] - ideDispatcher: top of loop
2019-04-25 12:36:46.853943 [ThreadId 13] - ideDispatcher: got request 4 with id: IdInt 2
2019-04-25 12:36:46.853967 [ThreadId 13] - ideDispatcher: top of loop
2019-04-25 12:36:46.853985 [ThreadId 13] - ideDispatcher: got request 4 with id: IdInt 2
2019-04-25 12:36:46.854006 [ThreadId 13] - ideDispatcher: top of loop
2019-04-25 12:36:46.854024 [ThreadId 13] - ideDispatcher: got request 4 with id: IdInt 2
2019-04-25 12:36:46.854048 [ThreadId 13] - ideDispatcher: top of loop
2019-04-25 12:36:46.854105 [ThreadId 6] - <--2--{"result":[],"jsonrpc":"2.0","id":2}

The full hie.log can be seen here: https://gist.github.com/skress/d16c5a7e65086b86dee2170c4791e2d4

Using hie with a project generated via stack new i.e. not using any stack template seems to work.

Any ideas what might cause this problem?
@skress
Copy link
Contributor Author

skress commented Apr 26, 2019 •
edited
Loading

EDIT: I am leaving the below comment as it is, but please note that the way how I compiled hie to use profiling did not really work well. See #1214 for how to compile hie properly with profiling support.

I have removed everything and restarted from scratch (and did not patch GHC again). As the problems still persist, I've tried to build hie with profiling enabled. Using the --profile option did not work (the compilation failed), I did install hie as follows:

stack install --stack-yaml stack-8.6.4.yaml --work-dir .stack-work-profile --library-profiling --force-dirty
stack install --stack-yaml stack-8.6.4.yaml --work-dir .stack-work-profile --executable-profiling

I switched to a custom hie wrapper script which runs hie like ~/.local/bin/hie "$@" +RTS -xc .

Using the VSCode plugin with a new project created via stack --resolver lts-13.15 new still works. My yesod project still fails.

The first problem was that dynamic libraries could not be loaded. The error was:

Got error while processing diagnostics: <command line>: can't load .so/.DLL for: libHSblaze-html-0.9.1.1-E0enfQtU1ZTDNQ8G8pIpJp.dylib (dlopen(libHSblaze-html-0.9.1.1-E0enfQtU1ZTDNQ8G8pIpJp.dylib, 5): image not found)

Please note the ending of that file name ...-E0enfQtU1ZTDNQ8G8pIpJp.dylib. That file is indeed not there, what is there are files which have the ghc version included, i.e. ...-E0enfQtU1ZTDNQ8G8pIpJp-ghc8.6.4.dylib.

I have absolutely no idea why it's that way. And I don't know why hie works with the simple stack project.

So I simply went to ~/.stack/snapshots/x86_64-osx/lts-13.15/8.6.4/lib/x86_64-osx-ghc-8.6.4 and created symlinks for all .dylib files to remove the -ghc8.6.4part. Additionally I needed to add that folder to DYLD_LIBRARY_PATH in my custom hie wrapper script.

Now I do not get the problem with the dynamic libraries anymore, but for the yesod project hie still fails with this error:

hie: internal error: PAP object entered!
    (GHC version 8.6.4 for x86_64_apple_darwin)
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

Any ideas what to try next? (Filing a GHC bug doesn't seem to be a good option for now ...)

@mpickering
Copy link
Collaborator

@skress Is the project public? It is possible this is a GHC bug though.

@skress
Copy link
Contributor Author

skress commented Apr 26, 2019

It is not a 'project' at all. All I did was to create a new yesod project from an existing template:

stack new yesod-test yesod-sqlite

That project gets created with lts-12.26 with a rather old ghc which has at least two bugs which prevents stack haddock from running, so I switched to lts-13.15 and changed a couple version boundaries for the project's dependencies. That's all I did. I did not change any line of code ...

@mpickering
Copy link
Collaborator

Thanks for the detailed bug report. Sorry that HIE didn't work for you so far. Someone will look into this issue and try to reproduce it. It would be good to isolate whether this only happens on OSX for example.

@fendor
Copy link
Collaborator

fendor commented Apr 26, 2019

I could reproduce it on NixOS, it didnt work either, so doesnt seem like OSX related problem.

@bscottm
Copy link

bscottm commented Apr 27, 2019 •
edited
Loading

Just to pipe in with a "Me too!": At first I thought the problem was with SublimeText, the LSP package and the Windows implementation of pipes. I tried hie-8.6.4 under Linux on VirtualBox, same problem. It seems to take about three or four JSON RPCs before hie-8.6.4 craps out. It's almost as if hie's stdout got closed because debugging keeps logging responses. More precisely, it seems like the write side of the pipe, which should be hie's stdout, gets closed.

LSP's basic loop calls Python's str.readline() to grab the next line of input looking for the "Content-length" header. That just stalls waiting for input. Hence, the conclusion that the hie side might have closed a handle/file descriptor, although, if it were actually closed, str.readline() would return an empty string (Python's EOF).

This particular problem showed up about two weeks ago, and I've been trying to diagnose it when I can free cycles.

@mpickering
Copy link
Collaborator

@bscottm Can you open a new issue please? It isn't clear to me that your problem is related to this at all.

In my experience errors such as

<command line>: can't load .so/.DLL for: libHSblaze-html-0.9.1.1-E0enfQtU1ZTDNQ8G8pIpJp.dylib (dlopen(libHSblaze-html-0.9.1.1-E0enfQtU1ZTDNQ8G8pIpJp.dylib, 5): image not found)

mean that the GHC that HIE was built with and version of GHC which build the shared object is different in some way. The one case I have seen this in particular is if you want to profile HIE you have to build it with a profiled version of GHC and then also have to build the project you want to load into HIE with profiling enabled.

In this case, do you have profiling enabled in your project?

I think creating symlinks and modifying the DYLD_LIBRARY_PATH isn't a way to fix it.

@mpickering
Copy link
Collaborator

Can you also try building HIE so that the final executable is dynamically linked?

@skress skress mentioned this issue Apr 27, 2019
Closed
@skress
Copy link
Contributor Author

skress commented Apr 28, 2019

I changed the way how to compile hie with profiling support (see #1214). Now I did not get any dylib problems like before, so it seems to have worked better. The net result is still the same, hie works with a simple stack new testproject but it fails with stack new yesodtest yesod-sqlite, but I do not get a GHC error anymore, instead hie terminates with a segmentation fault.

These are the last lines of the VSCode output:

*** Exception (reporting due to +RTS -xc): (THUNK), stack trace: 
  GhcMod.Target.loadTargets,
  called from GhcMod.Target.runGmlTWith',
  called from GhcMod.ModuleLoader.getModulesGhc,
  called from GhcMod.ModuleLoader.getModulesGhc',
  called from GhcMod.Error.gcatches,
  called from Haskell.Ide.Engine.Plugin.GhcMod.setTypecheckedModule.\,
  called from Haskell.Ide.Engine.PluginUtils.pluginGetFile,
  called from Haskell.Ide.Engine.Plugin.GhcMod.setTypecheckedModule,
  called from Haskell.Ide.Engine.Transport.LspStdio.requestDiagnosticsNormal.reqg,
  called from Haskell.Ide.Engine.Transport.LspStdio.requestDiagnosticsNormal,
  called from Haskell.Ide.Engine.Transport.LspStdio.requestDiagnostics,
  called from Haskell.Ide.Engine.Transport.LspStdio.reactor.loop,
  called from Haskell.Ide.Engine.Transport.LspStdio.reactor,
  called from Haskell.Ide.Engine.LSP.Reactor.runReactor,
  called from Haskell.Ide.Engine.Transport.LspStdio.run.dp.react,
  called from Haskell.Ide.Engine.Transport.LspStdio.run.dp.reactorFunc,
  called from Haskell.Ide.Engine.ModuleCache.withCradle,
  called from Haskell.Ide.Engine.ModuleCache.runActionWithContext,
  called from Haskell.Ide.Engine.Scheduler.ghcDispatcher.runner,
  called from Haskell.Ide.Engine.Scheduler.ghcDispatcher.runWithCallback,
  called from Haskell.Ide.Engine.Scheduler.ghcDispatcher.runIfVersionMatch,
  called from Haskell.Ide.Engine.Scheduler.ghcDispatcher,
  called from Control.Monad.Trans.Journal.runJournalT,
  called from GhcMod.Monad.runGhcModT',
  called from GhcMod.Monad.withGhcModEnv',
  called from GhcMod.Monad.withGhcModEnv,
  called from Control.Monad.Trans.Control.defaultLiftWith,
  called from Control.Monad.Trans.Control.defaultLiftBaseWith,
  called from Control.Monad.Trans.Control.control,
  called from Control.Monad.Trans.Control.liftBaseOp,
  called from GhcMod.Monad.runGmOutT',
  called from GhcMod.Monad.runGmOutT,
  called from GhcMod.Monad.runGhcModT,
  called from Haskell.Ide.Engine.PluginsIdeMonads.runIdeGhcM,
  called from Haskell.Ide.Engine.Scheduler.runScheduler.runGhcDisp,
  called from Control.Concurrent.Async.race,
  called from Control.Concurrent.Async.race_,
  called from Haskell.Ide.Engine.Scheduler.runScheduler,
  called from Haskell.Ide.Engine.Transport.LspStdio.run.dp,
  called from Language.Haskell.LSP.Core.handleMessage,
  called from Language.Haskell.LSP.Control.runWithHandles,
  called from Language.Haskell.LSP.Control.run,
  called from Haskell.Ide.Engine.Transport.LspStdio.run,
  called from Haskell.Ide.Engine.Transport.LspStdio.lspStdioTransport,
  called from Main.run,
  called from Main.main
/Users/skress/bin/my-hie-wrapper.sh: line 5:  5944 Segmentation fault: 11  $HOME/.local/bin/hie "$@" +RTS -xc
[Error - 8:34:39 PM] Connection to server got closed. Server will not be restarted.

@mpickering
Copy link
Collaborator

This is worrying. I'm not sure how we can debug this though. I will try to reproduce this on linux later this week.

@cah6 cah6 mentioned this issue Nov 15, 2019
Open
@jneira
Copy link
Member

jneira commented Jan 1, 2020

Not sure, but the last error mentions ghcmod and hie replaced it recently so maybe it could be fixed or at least the error will be different, @skress could you try with lastest master?

@skress
Copy link
Contributor Author

skress commented Jan 3, 2020

Thanks for the ping. I've tried it the last couple of hours with different settings/configurations. stack new yesodtest yesod-sqlite creates a new Yesod project that uses LTS-12.26 (GHC 8.4.4). I've used that config as well as an update to LTS-14.16 (GHC 8.6.5).

I am using VS Code with the plugin in version 0.0.31 (latest published version).

When I load the project the status bar stops at "Initializing Stack project: Settings.StaticFiles" and the logfile shows this error:

2020-01-03 09:21:38.545667 [ThreadId 5] - <--2--{"jsonrpc":"2.0","params":{"value":{"kind":"report","percentage":0.16666666666666666,"message":"Paths_yesodtest"},"token":0},"method":"$/progress"}
2020-01-03 09:21:38.582696 [ThreadId 5] - <--2--{"jsonrpc":"2.0","params":{"value":{"kind":"report","percentage":0.25,"message":"Settings"},"token":0},"method":"$/progress"}
2020-01-03 09:21:38.582867 [ThreadId 5] - <--2--{"jsonrpc":"2.0","params":{"value":{"kind":"report","percentage":0.3333333333333333,"message":"Settings.StaticFiles"},"token":0},"method":"$/progress"}
hie-8.6.5: loadObj: /private/var/folders/tj/8mwsk9sd6kb0b42k38t59_7r0000gn/T/ghc76435_0/ghc_16.o: file doesn't exist
2020-01-03 09:21:38.615668 [ThreadId 29] - Scheduler thread exited unexpectedly: loadObj "/private/var/folders/tj/8mwsk9sd6kb0b42k38t59_7r0000gn/T/ghc76435_0/ghc_16.o": failed

You can find the full log here: hie-2020-01-03.log

HIE doesn't crash, but when hovering over anything in the editor I only get "Loading ..." and VSCode's status bar still shows "Initializing Stack project: Settings.StaticFiles".

@jneira
Copy link
Member

jneira commented Jan 3, 2020

Thank you for testing it again and for the detailed report, i will try to reproduce

@jneira jneira self-assigned this Jan 3, 2020
@jneira
Copy link
Member

jneira commented Jan 12, 2020 •
edited
Loading

I tried it on windows and it seems to work fine, so it could be macos specific.
does the missing file path make some sense for you? does hie work for simple stack based projects?

@jneira jneira removed their assignment Jan 12, 2020
@skress
Copy link
Contributor Author

skress commented Jan 13, 2020

I can confirm that it also works for me on windows (tried it in a VM). On macOS I've tried the stack "servant" template and it works fine.

When opening a .hs file in the servant project a temporary folder (e.g. /private/var/folders/rx/6cf2s8fd33z4pt3xm_lkgrsc0000gn/T/ghc18597_0) gets created and within that folder files like ghc_5.o were created. Similar folders are created when running stack ghci in those projects.

For the yesod-simple project the error is loadObj "/private/var/folders/rx/6cf2s8fd33z4pt3xm_lkgrsc0000gn/T/ghc19251_0/ghc_14.o": failed but the ghc19251_0 folder does not even exist.

@jneira jneira mentioned this issue Jan 13, 2020
Open
@fendor
Copy link
Collaborator

fendor commented Jan 20, 2020

This looks like the initial error is solved and the current problem is the same as in #1520?
I would close it for now and focus on the issue #1520
Feel free to reopen if you think you are encountering a different error.

@fendor fendor closed this as completed Jan 20, 2020
@skress skress mentioned this issue Jan 26, 2020
Open
@skress skress mentioned this issue Mar 24, 2020
Open
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
os: macOS
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@jneira @bscottm @skress @mpickering @fendor