-
Notifications
You must be signed in to change notification settings - Fork 73
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ghcup binary built on i386/alpine-3.16 with GHC-9.4.8 segfaults (statically linked) #962
Comments
Wonder if there might be a correlation to https://gitlab.haskell.org/ghc/ghc/-/commit/9b645ee1a9fff64b66b36dc73d8809ff82025829 which is part of 9.4.8. |
Tried with alpine-3.16, no change. |
@hasufell wrt. bisecting this bug, what is the latest known-good version of GHC prior to 9.4.8? I see CI uses 8.10.7; is that it? Also, do you know if this issue still exists with latest GHC, or do we have a known-good GHC version that is later than 9.4.8? |
There is not much known. |
Before my EOD Sunday I fired off some CI runs with various GHC versions to make a coarse bisect. Result:
Would be nice to test more finely around 9.4.* and 9.2.* but there aren't many bindists available for alpine/i386:
|
@hasufell I'm trying to reproduce this locally. But I'm unable to locally run the script that reproduces the issue in CI because the script needs the Here's the command I'm running:
It's failing with the error |
Command for reproducing locally:
Logs:
|
Verbose logs:
|
So, it appears executing the configure script makes GHCup segfault. In an attempt to arrive at a more minimal example, I tried using the Next, I plan to see if I can trigger the segfault using only |
Update: as stated above, I assumed there was a problem with the configure script, as the segfault seemed to occur when running this script. So, in an attempt to arrive at more minimal reproduction, I wanted to see if running the configure script manually with the same arguments and CWD also produces a segfault. To accomplish this I made this commit 8cb52da, which prints the CWD and configure script command to run and then sleeps, so that it can be run manually in a terminal. Surprisingly, however, this results in the So it appears the relation to the configure script was a red herring. |
So a minimal program calling threadDelay segfaults? |
Next question would be if this happens with -threaded or not, as well. |
This crash is unrelated to threadDelay, and it happens when freeing memory due to
By adding a delay just after doing unpack of the tar I could reproduce the crash in
|
I can try and build an i386 binary that uses Hasell tar instead of libarchive, as a workaround. |
The bindist used is: https://downloads.haskell.org/~ghcup/unofficial-bindists/ghc/9.4.8/ghc-9.4.8-i386-alpine-linux.tar.xz
It is a dynamically linked bindist, because the static ones are more broken.
The settings file is as follows
The linker is indeed
ld.bfd
, so I believe we're not hitting https://gitlab.haskell.org/ghc/ghc/-/issues/17508The backtrace isn't very useful
The
ptr=0x4000000c
in frame 1 is reproducible/stable.plan.json of the ghcup build is here: https://gist.github.com/hasufell/22433e37c7694ff758f63d6dbbf1421f
CI run uncovering the issue: https://github.com/haskell/ghcup-hs/actions/runs/7385090589/job/20090951278#step:6:454
I'm not sure this is enough to create a GHC bug report, especially since it's an unofficial bindist compiled manually. It's possible this is also just another alpine f**kup. Their toolchain has not been great lately, which is why I've still been on 3.12 with older GHCs.
@bgamari @runeksvendsen @angerman
The text was updated successfully, but these errors were encountered: