I am only seeing this on Fedora s390x architecture.
gdb backtrace of cabal-install-3.10.1.0-1.fc39.s390x core dump inside fedora:39
(gdb) bt#0 0x000000008000e008 in evacuate1 ()#1 0x0000000083f3c9b6 in scavenge_loop1 ()#2 0x0000000083f31cbc in scavenge_until_all_done ()#3 0x0000000083f334fa in GarbageCollect ()#4 0x0000000083f1dce2 in scheduleDoGC ()#5 0x0000000083f1ee90 in schedule ()#6 0x0000000083f1f6de in scheduleWaitThread ()#7 0x0000000083f19610 in hs_main ()#8 0x000000008003226e in main ()
I am afraid that is all I have right now.
Expected behavior
No crash
Environment
GHC version used: 9.2.6 and 9.4.5
Optional:
Operating System: Fedora Linux
System Architecture: s390x
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related or that one is blocking others.
Learn more.
Without having cabal working on F39 it is hard to experiment. Would you suggest to compile a different cabal version on F38 and use that in order to bootstrap a newer version of cabal in F39? Beside that I was wondering why dnf debuginfo-install cabal-install is failing for me. Are the debuginfo repositories not available so far?
If this only happens when .cabal is not present, perhaps it's something to do with looking up environment variables and the XDG configuration.. seems a long shot though.
@stefansf I think F38 cabal-install works on F39 probably (I also have some copr repos).
(Also cabal-install can be bootstrapped/built without cabal-install of course: though it is a bit tedious.) I wonder if building with 9.6 also helps.
@mpickering I simplified a bit: just the ~/.cabal/ dir is definitely not sufficient,
whereas a fully prepped "cache" there seems to (help) avoid the segfault.
Anyway I can access a s390x machine and will try to dig into the cabal-install code more later
to narrow down the problem.
I built cabal-3.8.1.0 with stack --resolver lts (currently still ghc-9.4.7) and it also segfaults for me.
However cabal-install-3.10.2.1 built with stack --resolver nightly (currently ghc-9.6.3) does not segfault for me.
Also I think you can kind of ignore most of what I said about ~/.cabal/ earlier since I can get segfaults with cabal-3.8 even with a fully populated ~/.cabal/packages/.
Also BTW ghc9.4-9.4.8 is available for F39 in updates-testing.
Though I haven't tried it and doubt it makes a difference,
since cabal-3.8 segfaults happen for builds with both with 9.4 and 9.6.
At least cabal-3.8.1.0 build there seems to crash for me in waitCatch (Cabal-3.8.1.0/src/Distribution/Compat/Async.hs) while calling catch probably. waitCatch is called by rawSystemStdInOut (Cabal-3.8.1.0/src/Distribution/Simple/Utils.hs). (I am building cabal-install with -O0 which may crash more consistently.)
I am just doing tedious debug by print statements...
@juhp We recently moved to GHC 9.4.7 and cabal-install 3.8.1.0 in Debian, and we are not experiencing this issue on s390x. cabal update works for me, with or without a ~/.cabal directory.
Not sure if this has to do with any of the GHC patches we have backported on top of 9.4.7, or the build toolchain in Debian vs Fedora, but hopefully this give you something to compare against.
The other interesting thing is that I get different output (with -O0) for -v1 and -v2/-v3.
So it actually crashes earlier for me with higher verbosity.