Segfault when running hls with TH and libpq #1982
Comments
|
I can't reproduce from nixos using stacks nix integration to provide libpq using 9cbac50d530397ed519a6c76cfdeed645d9f8956, I might be able to try from an ubuntu vm later: @aschmois Can you see if you get a segfault after checking my branch out at that commit? Nothing more than a stack build should be needed on your part after switching branches. EDIT: For completeness here's this output: |
Same! Let's see, if we assume that whatever is on the search pages of ubuntu and nix package search respectively then: nix stable: postgres Version: 11.12 So we are almost certainly using different major versions, potentially a difference of two major versions. |
|
I added a recent commit to my fork which tries different postgres versions. Upon re-reading your description though, It looks like I needed to clone that external library to reproduce? I assumed that cloning the repo was enough to reproduce. |
|
Ok I have reproduced with all of the above versions. |
|
The segfault only happens if you run with I bet if you use the binary directly rather than the wrapper you won't get this segfault. |
jneira
added
type: bug
|
So how did you reproduce this @codygman? This sounds similar to all the other issues with the in-built linker. Can you reproduce with a dynamically linked ghcide? |
|
@mpickering I did reproduce with a nix install of I'm not sure if the nix version is dynamically linked or not. I don't have time now, but I'll add it to my to do list. |
|
This one was bizarre and triggering it requires:
Note this isn't reproducible with cabal. It also doesn't happen using haskell-language-server from nix on Ubuntu using Open questions:
This investigation was done during working hours earlier with @aschmois, so I hope that I'm not sure I have all the details about correct. If I have the time tomorrow or this weekend I plan to try and make a minimal reproduction and dig into this a little more. If any of this strangeness is familiar to anyone though, any advice or help is appreciated. |
|
I did some more research and it looks like "p11-kit cannot be used as a static library":
The author says:
It really feels like this could be related, but this is not my area of expertise. |
|
And another related issue here: nh2/static-haskell-nix#86
|
|
Another thing potentially interesting is that when testing this using It's possible that that test timing out isn't too surprising, but since it was a golden test I assumed it might be fast. It's also possible that even if this isn't directly related to this, it deserves its own issue. |
|
Finally I read something in a related issue that makes me wonder if GHC's dynamic linker is getting used in this particular case:
From: #469 (comment) |
|
To summarize:
|
|
Thank you for your investigation! The ghc built-in linker is used only when HLS is statically linked, which is the case for the binaries distributed from the GitHub project page, ghcup, and Nix. You can ask your binary whether it's statically or dynamically linked as follows:
Can you confirm that the segfault with |
No problem! We really want to help Haskell language server be an option in Industry for everyone including ourselves and our fairly large and complicated work codebase.
Yes, I can confirm that. We tested 5-10 times say in an empty ubuntu Docker container with:
I can't make a copy/paste repro yet, but it's on my to-do list. |
|
The next step in this process is to reproduce with plain GHC using a static build and GHCi:
|
|
An alternative way to build GHC from source is: |
|
@codygman Do you know how to reproduce this on NixOS? I have built a static version of GHC and loading the example project using |
|
I think this is fixed in 8.10.7 |
|
I think this is also relevant to: We use Seems all related to be related to Static vs Dynamic linking issues, and pending Template Haskell fix in GHC here: (Just leaving this here as a note for others/organizational purposes)
FWIW, I tried with |
@mpickering I only remember reproducing this with |
|
I am gonna close this issue as all compiler crashes seems to have the same root cause:
If any of you think the issue should not be included generically feel free to reopen it (with a brief explanation if possible) |
Your environment
Output of
haskell-language-server --probe-toolsorhaskell-language-server-wrapper --probe-tools:haskell-language-server-wrapper --probe-tools haskell-language-server version: 1.1.0.0 (GHC: 8.10.4) (PATH: /home/andres/.ghcup/bin/haskell-language-server-wrapper-1.1.0) (GIT hash: f1c096927186a93d8e3ccd4fe8385cc1b070350b) Tool versions found on the $PATH cabal: 3.4.0.0 stack: 2.7.1 ghc: 8.10.4Which OS do you use:
Ubuntu 20.04
Which lsp-client do you use:
VS Code (but irrelevant to the problem)
Describe your project (alternative: link to the project):
https://github.com/aschmois/th-pq-segfault
Steps to reproduce
Run
haskell-language-server-wrapperExpected behaviour
Completed hls command
Actual behaviour
Segfault exit
Include debug information
Execute in the root of your project the command
haskell-language-server --debug .and paste the logs here:Debug output:
Me and a collegue went down the route to figure out why we were getting segfaults when compiling our project. We drilled down until we could get the smallest reproducible project. The issue ends up being that if you import a project that loads
pq(or libpq) regardless of its contents you get a segfault with no information as to why. If your own project importspqit does not segfault. If you depend on a project that imports pq but don't import that project then it won't segfault. It was very interesting to reach this conclusion. You can play around with the example project to see what segfaults and what doesn't. I would be interested to see if different OS's react differently though. Also it's possible that my libpq is at fault as well.The text was updated successfully, but these errors were encountered: