Open jackjohn7 opened 8 months ago
Interesting, I'll investigate that.
I have CI self hosted runners that are using AMD Ryzen™ 7 7700. And I definitely cannot reproduce it there.
I have not tried Nobara Linux, but I can't see how that would be relevant.
Are you running under some KVM cloud stuff?
No cloud stuff. It's just an ordinary desktop I use for development and gaming. I haven't had any similar issues with other toolchains.
Can you provide the coredump?
Output of coredumpctl gdb
PID: 6116 (ghcup)
UID: 1000 (jack)
GID: 1000 (jack)
Signal: 4 (ILL)
Timestamp: Sat 2024-02-17 00:02:51 CST (18min ago)
Command Line: ghcup list
Executable: /home/jack/.ghcup/bin/ghcup
Control Group: /user.slice/user-1000.slice/user@1000.service/app.slice/app-alacritty-83b7a964c25042d99cc6b8b07d91d3a7.scope
Unit: user@1000.service
User Unit: app-alacritty-83b7a964c25042d99cc6b8b07d91d3a7.scope
Slice: user-1000.slice
Owner UID: 1000 (jack)
Boot ID: 19b6995a4b854a37986f6783f7a25360
Machine ID: 88cbced372bf4c199ac9a3e7ffeffceb
Hostname: nobara-pc
Storage: /var/lib/systemd/coredump/core.ghcup.1000.19b6995a4b854a37986f6783f7a25360.6116.1708149771000000.zst (present)
Size on Disk: 1.5M
Message: Process 6116 (ghcup) of user 1000 dumped core.
Module /home/jack/.ghcup/bin/ghcup without build-id.
Stack trace of thread 6116:
#0 0x0000000000f14e1a n/a (/home/jack/.ghcup/bin/ghcup + 0xb14e1a)
ELF object binary architecture: AMD x86-64
GNU gdb (Fedora Linux) 14.1-4.fc39
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /home/jack/.ghcup/bin/ghcup...
(No debugging symbols found in /home/jack/.ghcup/bin/ghcup)
[New LWP 6116]
[New LWP 6118]
[New LWP 6117]
[New LWP 6120]
[New LWP 6119]
This GDB supports auto-downloading debuginfo from the following URLs:
<https://debuginfod.fedoraproject.org/>
Enable debuginfod for this session? (y or [n]) y
Debuginfod has been enabled.
To make this setting permanent, add 'set debuginfod enabled on' to .gdbinit.
Downloading separate debug info for system-supplied DSO at 0x7ffee4da0000
Core was generated by `ghcup list'.
Program terminated with signal SIGILL, Illegal instruction.
#0 0x0000000000f14e1a in ?? ()
[Current thread is 1 (LWP 6116)]
I have a massive dump file (8000+ lines) as well. Would that be useful?
Yes
CCing @bgamari in case this might be interesting
I've included a google drive link to the file since it's too large to be attached here https://drive.google.com/file/d/1IkbqgBa19s33RvzReV1J1U7S3jzzCWKf/view?usp=sharing
I've included a google drive link to the file since it's too large to be attached here https://drive.google.com/file/d/1IkbqgBa19s33RvzReV1J1U7S3jzzCWKf/view?usp=sharing
@jackjohn7 you can attach it here if you zip it: core_dump.zip
Very odd. Indeed it appears the executable jumped into the middle of an abyss:
>>> x/8i $pc
=> 0xf14e1a: add %al,(%rax)
0xf14e1c: add %al,(%rax)
0xf14e1e: add %al,(%rax)
Even stranger, the Haskell stack register is complete nonsense.
>>> print $rbp
$1 = (void *) 0x12
Something has gone horribly wrong in this program.
I have tried to reproduce this locally with Nobara 39 running under a VM on a Ryzen 5900X to no avail.
@jackjohn7, a few questions:
ghcup
from source with the Nobara packaged toolchain and confirm that the issue in not reproducible?--help
. During installation using the script, after it installs everything, it seems to attempt to do ghcup list
or something similar and it fails. It'll fail when I execute just about any command. Edit: It may be trying to run the install
command to install ghc, hls, or stack. It doesn't finish though, so I can't really see the output hahaAVX512 was disabled for my CPU. I carelessly disabled this feature for playing a particular game. Re-enabling it seems to have fixed the issue entirely. That or updating my system may have effected it. In any case, the toolchain is now working for me.
I see this got tagged as a bug. Was this reproduced for anyone else?
I'm using Nobara Linux which is based on Fedora.
When I execute the
curl --proto '=https' --tlsv1.2 -sSf https://get-ghcup.haskell.org | sh
command listed on the homepage for the website I respond to all the configuration prompts and it seems to install properly. Then when the script goes to execute ghcup, I'm met with this output:After this, I tried installing ghcup through the binaries on the file server linked in the documentation for those who don't like
curl | sh
. I used the most recent x86_64-linux binary. I placed it in the same location that the installation script does, and I added the location to my path. I get the same error when I attempt to use a command (only --help doesn't fail):It seems to be running an illegal CPU instruction in any case. I don't see how this could be. I'm using an x86_64 processor (ryzen 7 7700x). Output of
lscpu
below.I didn't see another issue quite like this and I couldn't find anyone else with the same issue on Google. I've just verified that the latest installation works fine on my Fedora laptop also using x86_64 (ryzen 5 5500u).
I tried seeing if the esoteric distros section of the installation docs could help, but nothing I tried there worked either. https://www.haskell.org/ghcup/install/#esoteric-distros
I can use GHC, and cabal-install provided by my package manager for the time being, but I thought I should still report this in case someone encounters something similar.