GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2023-06-15T17:00:11Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/23455Binder-swap for singletons looks fishy2023-06-15T17:00:11ZAdam GundryBinder-swap for singletons looks fishyReading #21229 and `Note [Care with binder-swap on dictionaries]`, I wondered if there might not be a similar issue with singletons such as `SNat` as there is with dictionaries. Perhaps this is related to #23109?
Imagine we had this:
``...Reading #21229 and `Note [Care with binder-swap on dictionaries]`, I wondered if there might not be a similar issue with singletons such as `SNat` as there is with dictionaries. Perhaps this is related to #23109?
Imagine we had this:
```hs
f :: forall (a :: Natural) . SNat a -> blah
h = \ @(a :: Natural) (snat :: SNat a)
let co = SNat[0] <a> :: SNat a ~R# Natural
case snat |> co of wild
0 -> f @0 (0 |> sym (SNat[0] <0>))
1 -> f @a snat
```
Now we can binder-swap (`snat` is not a dictionary Id) and unfold `wild` to get
```hs
h = \ @(a :: Natural) (snat :: SNat a)
let co = SNat[0] <a> :: SNat a ~R# Natural
case snat |> co of wild
0 -> f @0 (0 |> sym (SNat[0] <0>))
1 -> f @a (1 |> sym co)
```
Unlike the example from the Note, we do not directly specialise `f @a d` to `f @a (1 |> sym co)` because the argument is not a dictionary. But `f @a (1 |> sym co)` still seems problematic, because it is valid only within the body of the case (outside of the case we have no reason to believe that the `a = 1`), but there is nothing to stop it floating.
Here's a more concrete example:
```hs
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE TypeFamilies #-}
module SNatBinderSwap where
import Data.Kind (Type)
import Data.Type.Equality
import GHC.TypeNats
type G :: Nat -> Type -> Type -> Type
type family G n s t where
G 0 s _ = s
G _ _ t = t
newtype N n s t = MkN { unN :: G n s t }
{-# NOINLINE f #-}
f :: SNat a -> N a Bool Char
f x | Just Refl <- testEquality x (SNat @0) = MkN True
| Just Refl <- testEquality x (SNat @1) = MkN 'x'
h :: SNat a -> N a Bool Char
h snat
| Just Refl <- testEquality snat (SNat @1) = f snat
| Just Refl <- testEquality snat (SNat @0) = f snat
```
Compiling this with 9.6.1 gives:
```hs
h2 :: Natural
h2 = NS 0##
h1 :: forall {a :: Nat}. N a Bool Char
h1
= \ (@(a_aHj :: Nat)) ->
f @a_aHj (h2 `cast` <Co:3> :: Natural ~R# SNat a_aHj)
h :: forall (a :: Nat). SNat a -> N a Bool Char
h = \ (@(a_aHj :: Nat)) (snat_X1 :: SNat a_aHj) ->
case snat_X1 `cast` <Co:2> :: SNat a_aHj ~R# Natural of wild_aJ1 {
NS x1_aJ2 ->
case x1_aJ2 of {
__DEFAULT -> case h3 of wild2_00 { };
0## -> h1 @a_aHj;
1## -> f @a_aHj (wild_aJ1 `cast` <Co:3> :: Natural ~R# SNat a_aHj)
};
NB x1_aJa -> case h3 of wild1_00 { }
}
```
Now `h1` looks fishy. It claims to have type `N a Bool Char`, but its implementation passes 0 as the evidence for `SNat a`. Hence it will always evaluate to `MkN True`, and if we were to somehow arrange to call `h1` at some non-zero `Nat`, we would have a type soundness bug.
I haven't yet managed to construct an example that actually exploits this. But is there some principled reason why it is safe, or are we just relying on being lucky?
Perhaps the underlying issue here is that `SNat` is not a "real" singleton type, so we don't have a way to pattern-match on it and keep track of the evidence that we have done so.Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/23452CallConv causes SIGSEGV with --disable-tables-next-to-code2023-05-30T14:50:26ZGreg SteuckCallConv causes SIGSEGV with --disable-tables-next-to-codeWhen building with `--disable-tables-next-to-code` on OpenBSD-amd64
`testsuite/tests/codeGen/should_run/CallConv.hs` seems to not be using the right
calling convention. The continuation address pointed at by `%rbp` is not
sensible in thi...When building with `--disable-tables-next-to-code` on OpenBSD-amd64
`testsuite/tests/codeGen/should_run/CallConv.hs` seems to not be using the right
calling convention. The continuation address pointed at by `%rbp` is not
sensible in this case.
```
(gdb) bt
#0 0x0000000000354048 in someFuncF ()
#1 0x0000000000000000 in ?? ()
(gdb) disassemble
Dump of assembler code for function someFuncF:
=> 0x0000000000354048 <+0>: movss %xmm1,%xmm0
0x000000000035404c <+4>: subss %xmm2,%xmm0
0x0000000000354050 <+8>: addss %xmm2,%xmm1
0x0000000000354054 <+12>: movss %xmm0,%xmm2
0x0000000000354058 <+16>: movss %xmm3,%xmm0
0x000000000035405c <+20>: divss %xmm4,%xmm0
0x0000000000354060 <+24>: mulss %xmm4,%xmm3
0x0000000000354064 <+28>: movss %xmm0,%xmm4
0x0000000000354068 <+32>: jmpq *0x0(%rbp)
End of assembler dump.
(gdb) p/x $rbp
$1 = 0x2af505330
(gdb) p/x *((uint64_t*) $rbp)
$2 = 0x6882c0
(gdb) disassemble 0x00000000006882c0
No function contains specified address.
(gdb) c
Program received signal SIGSEGV, Segmentation fault.
0x00000000006882c0 in ?? ()
```
I guess this assembly code relies on TNTC and so the test should be made conditional on that setting.Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/23451Build error: fixup value out of range when ipe flavour transformer turned on2023-09-07T09:12:05ZIan-Woo KimBuild error: fixup value out of range when ipe flavour transformer turned onWhen I try to build GHC with `ipe` flavour transformer, the build failed here: (when compiling GHC.Parser)
```
$ hadrian/build -j --flavour=Quick+ipe
...
| Run Ghc CompileHs Stage1: compiler/GHC/Tc/Solver.hs => _build/stage1/compiler/bui...When I try to build GHC with `ipe` flavour transformer, the build failed here: (when compiling GHC.Parser)
```
$ hadrian/build -j --flavour=Quick+ipe
...
| Run Ghc CompileHs Stage1: compiler/GHC/Tc/Solver.hs => _build/stage1/compiler/build/GHC/Tc/Solver.o
Command line: _build/stage0/bin/ghc -Wall -Wcompat -dynamic-too -hisuf hi -osuf o -hcsuf hc -static -hide-all-packages -no-user-package-db '-package-env -' '-package-db _build/stage1/inplace/package.conf.d' '-this-unit-id ghc-9.7-inplace' '-package-id array-0.5.5.0-inplace' '-package-id base-4.18.0.0-inplace' '-package-id binary-0.8.9.1-inplace' '-package-id bytestring-0.11.4.0-inplace' '-package-id containers-0.6.7-inplace' '-package-id deepseq-1.4.8.1-inplace' '-package-id directory-1.3.8.1-inplace' '-package-id exceptions-0.10.7-inplace' '-package-id filepath-1.4.100.1-inplace' '-package-id ghc-boot-9.7-inplace' '-package-id ghc-heap-9.7-inplace' '-package-id ghci-9.7-inplace' '-package-id hpc-0.6.2.0-inplace' '-package-id process-1.6.17.0-inplace' '-package-id semaphore-compat-1.0.0-inplace' '-package-id stm-2.5.1.0-inplace' '-package-id template-haskell-2.20.0.0-inplace' '-package-id time-1.12.2-inplace' '-package-id transformers-0.6.1.0-inplace' '-package-id unix-2.8.1.0-inplace' -i -i/Users/ianwookim/repo/srcc/ghcHEAD/_build/stage1/compiler/build -i/Users/ianwookim/repo/srcc/ghcHEAD/_build/stage1/compiler/build/autogen -i/Users/ianwookim/repo/srcc/ghcHEAD/compiler -Irts/include -I_build/stage1/compiler/build -I_build/stage1/compiler/build/. -Icompiler/. -I/Users/ianwookim/repo/srcc/ghcHEAD/libraries/process/include -I/Users/ianwookim/repo/srcc/ghcHEAD/_build/stage1/libraries/process/build/include -I/Users/ianwookim/repo/srcc/ghcHEAD/libraries/directory -I/Users/ianwookim/repo/srcc/ghcHEAD/_build/stage1/libraries/directory/build -I/Users/ianwookim/repo/srcc/ghcHEAD/libraries/unix/include -I/Users/ianwookim/repo/srcc/ghcHEAD/_build/stage1/libraries/unix/build/include -I/Users/ianwookim/repo/srcc/ghcHEAD/libraries/time/lib/include -I/Users/ianwookim/repo/srcc/ghcHEAD/_build/stage1/libraries/time/build/lib/include -I/Users/ianwookim/repo/srcc/ghcHEAD/libraries/containers/containers/include -I/Users/ianwookim/repo/srcc/ghcHEAD/_build/stage1/libraries/containers/containers/build/include -I/Users/ianwookim/repo/srcc/ghcHEAD/libraries/bytestring/include -I/Users/ianwookim/repo/srcc/ghcHEAD/_build/stage1/libraries/bytestring/build/include -I/Users/ianwookim/repo/srcc/ghcHEAD/libraries/base/include -I/Users/ianwookim/repo/srcc/ghcHEAD/_build/stage1/libraries/base/build/include -I/Users/ianwookim/repo/srcc/ghcHEAD/libraries/ghc-bignum/include/ -I/Users/ianwookim/repo/srcc/ghcHEAD/_build/stage1/libraries/ghc-bignum/build/include/ -I/Users/ianwookim/repo/srcc/ghcHEAD/rts/include -I/Users/ianwookim/repo/srcc/ghcHEAD/_build/stage1/rts/build/include -optP-include -optP_build/stage1/compiler/build/autogen/cabal_macros.h -optc--target=arm64-apple-darwin -optP-DHAVE_INTERNAL_INTERPRETER -optP-DCAN_LOAD_DLL -outputdir _build/stage1/compiler/build -fdiagnostics-color=always -Wall -Wno-name-shadowing -Wnoncanonical-monad-instances -Wnoncanonical-monoid-instances -XHaskell2010 -XNoImplicitPrelude -XBangPatterns -XScopedTypeVariables -XMonoLocalBinds -XTypeOperators -no-global-package-db -package-db=/Users/ianwookim/repo/srcc/ghcHEAD/_build/stage1/inplace/package.conf.d -ghcversion-file=rts/include/ghcversion.h -ghcversion-file=rts/include/ghcversion.h -Wnoncanonical-monad-instances -optc-Wno-unknown-pragmas -optP-Wno-nonportable-include-path -c _build/stage1/compiler/build/GHC/Parser.hs -o _build/stage1/compiler/build/GHC/Parser.o -O0 -H64m -finfo-table-map -fdistinct-constructor-tables -fno-ignore-interface-pragmas -fcmm-sink -haddock -Winvalid-haddock -Wno-deprecated-flags -Wcpp-undef
===> Command failed with error code: 1
/tmp/nix-shell.eNdd3H/ghc58850_0/ghc_3.s:36865:2: error:
error: fixup value out of range
b.hi LcHST
^
|
36865 | b.hi LcHST
| ^
/tmp/nix-shell.eNdd3H/ghc58850_0/ghc_3.s:36883:2: error:
error: fixup value out of range
b.hi LcHSW
^
|
36883 | b.hi LcHSW
| ^
...
```
building GHC 9.7.20230522
on Aarch64 macbook m1, macOS 13.2.19.8.2Andreas KlebingerAndreas Klebingerhttps://gitlab.haskell.org/ghc/ghc/-/issues/23397RTS memory return behaviour is incorrect for non-moving GC2024-02-27T13:03:55ZMatthew PickeringRTS memory return behaviour is incorrect for non-moving GCIn https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10381#note_498455: @teo says:
> @mpickering apologies for not catching this before this got merged, but I don't think this is right for the case when `gen` is `oldest_gen` and we ar...In https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10381#note_498455: @teo says:
> @mpickering apologies for not catching this before this got merged, but I don't think this is right for the case when `gen` is `oldest_gen` and we are using the non-moving gc. Then `oldest_gen->n_blocks` should be counted along with uncopied things as it's the blocks that make up segments I think9.8.2Teo CamarasuTeo Camarasuhttps://gitlab.haskell.org/ghc/ghc/-/issues/23393Exponential Core generation regression in GHC 9.42023-07-07T08:12:46ZTeo CamarasuExponential Core generation regression in GHC 9.4We recently upgraded to GHC 9.4.5 at work (from 9.2). This in general has improved compile times, but one of the modules has regressed badly. It used to compile quickly but now takes 88s.
It features a large record type with a hand-writ...We recently upgraded to GHC 9.4.5 at work (from 9.2). This in general has improved compile times, but one of the modules has regressed badly. It used to compile quickly but now takes 88s.
It features a large record type with a hand-written `FromJSON` instance.
My suspicion is that some change in the optimiser is leading to Core exponential in the amount of fields.
I've uploaded a pared down reproducer here: https://gitlab.haskell.org/teo/aeson-exponential-code-repro .
Unfortunately it still depends on aeson, so it is quite heavy.
You should be able to build it by running:
```
nix develop
cabal build
```
I've tried building this with a few different versions of GHC and this is what I get:
| GHC version | time taken (s) | -dump-simpl size (bytes) |
| ------ | ------ | ---- |
| 9.2.7 | 3s | 553K |
| 9.4.5 | 34s | 48M |
| 9.6.1 | 25s | 48M |9.4.6https://gitlab.haskell.org/ghc/ghc/-/issues/23392attempting to use module ‘gi-gtk-3.0.41-inplace:GI.Gtk.Objects.IconFactory’ (...2024-02-27T14:01:41Zhamishmackattempting to use module ‘gi-gtk-3.0.41-inplace:GI.Gtk.Objects.IconFactory’ (./GI/Gtk/Objects/IconFactory.hs) which is not loaded## Summary
When building `gi-gtk-3.0.41` with ghc 9.6.1 and -j2 (or above) we get:
```
[220 of 708] Compiling GI.Gtk.Objects.Settings ( GI/Gtk/Objects/Settings.hs, /run/user/1004/tmp.Gox7zEaBXe/gi-gtk-3.0.41/dist-newstyle/build/x86_64-...## Summary
When building `gi-gtk-3.0.41` with ghc 9.6.1 and -j2 (or above) we get:
```
[220 of 708] Compiling GI.Gtk.Objects.Settings ( GI/Gtk/Objects/Settings.hs, /run/user/1004/tmp.Gox7zEaBXe/gi-gtk-3.0.41/dist-newstyle/build/x86_64-linux/ghc-9.6.1/gi-gtk-3.0.41/build/GI/Gtk/Objects/Settings.o, /run/user/1004/tmp.Gox7zEaBXe/gi-gtk-3.0.41/dist-newstyle/build/x86_64-linux/ghc-9.6.1/gi-gtk-3.0.41/build/GI/Gtk/Objects/Settings.dyn_o )
<no location info>: error:
attempting to use module ‘gi-gtk-3.0.41-inplace:GI.Gtk.Objects.IconFactory’ (./GI/Gtk/Objects/IconFactory.hs) which is not loaded
```
## Steps to reproduce
Install ghc 9.6.1, cabal and gtk+ 3 then run
```
cabal unpack gi-gtk-3.0.41
cd gi-gtk-3.0.41
cabal build --ghc-options=-j2
```
## Expected behavior
The code should compile with `-j2` (since it does with `-j1`).
## Environment
I used the following nix-shell to get ghc, cabal and gtk.
```
$ nix-shell -E '((import (builtins.fetchGit { url="https://github.com/input-output-hk/haskell.nix"; rev = "55702bf3f287c381edd8a8b1ba49b9ab29be7bb0"; }) {}).pkgs-unstable.haskell-nix.hackage-project { compiler-nix-name = "ghc961"; name = "gi-gtk"; version = "3.0.41"; }).shellFor { tools.cabal = {}; }'
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 9.6.1
$ cabal --version
cabal-install version 3.10.1.0
compiled using version 3.10.1.0 of the Cabal library
$ pkg-config --modversion gtk+-3.0
3.24.37
```
* Operating System: linux
* System Architecture: x86_649.12.1Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/23375RTS error: scavenge_one: strange object 23 while using byte-code linking in c...2023-10-18T17:02:42ZIan-Woo KimRTS error: scavenge_one: strange object 23 while using byte-code linking in compilationOn x86_64 linux system, we turn on byte-code linking (`-fprefer-byte-code -fbyte-code-and-object-code`) and we increasingly get this error in GC during compiling a project (the following is an excerpt from CI message)
```
> ghc-9....On x86_64 linux system, we turn on byte-code linking (`-fprefer-byte-code -fbyte-code-and-object-code`) and we increasingly get this error in GC during compiling a project (the following is an excerpt from CI message)
```
> ghc-9.6.1: internal error: scavenge_one: strange object 23
> Stack trace:
> 0x7fffef186bc0 set_initial_registers (/nix/store/59ng7169ncp4g0xcyxdmd5bf5gd9yilm-ghc-9.6.1/lib/ghc-9.6.1/lib/x86_64-linux-ghc-9.6.1/libHSrts-1.0.2_thr-ghc9.6.1.so)
> 0x7fffeeddd5c8 dwfl_thread_getframes (/nix/store/sd6nsyj6v8qmdr07g5hl5rp8mpkbzasp-elfutils-0.189/lib/libdw-0.189.so)
> 0x7fffeeddd11b get_one_thread_cb (/nix/store/sd6nsyj6v8qmdr07g5hl5rp8mpkbzasp-elfutils-0.189/lib/libdw-0.189.so)
> 0x7fffeeddd42a dwfl_getthreads (/nix/store/sd6nsyj6v8qmdr07g5hl5rp8mpkbzasp-elfutils-0.189/lib/libdw-0.189.so)
> 0x7fffeeddd957 dwfl_getthread_frames (/nix/store/sd6nsyj6v8qmdr07g5hl5rp8mpkbzasp-elfutils-0.189/lib/libdw-0.189.so)
> 0x7fffef187297 libdwGetBacktrace (/nix/store/59ng7169ncp4g0xcyxdmd5bf5gd9yilm-ghc-9.6.1/lib/ghc-9.6.1/lib/x86_64-linux-ghc-9.6.1/libHSrts-1.0.2_thr-ghc9.6.1.so)
> 0x7fffef18fb27 rtsFatalInternalErrorFn (/nix/store/59ng7169ncp4g0xcyxdmd5bf5gd9yilm-ghc-9.6.1/lib/ghc-9.6.1/lib/x86_64-linux-ghc-9.6.1/libHSrts-1.0.2_thr-ghc9.6.1.so)
> 0x7fffef18fd1d barf (/nix/store/59ng7169ncp4g0xcyxdmd5bf5gd9yilm-ghc-9.6.1/lib/ghc-9.6.1/lib/x86_64-linux-ghc-9.6.1/libHSrts-1.0.2_thr-ghc9.6.1.so)
> 0x7fffef1bccb4 scavenge_one (/nix/store/59ng7169ncp4g0xcyxdmd5bf5gd9yilm-ghc-9.6.1/lib/ghc-9.6.1/lib/x86_64-linux-ghc-9.6.1/libHSrts-1.0.2_thr-ghc9.6.1.so)
> 0x7fffef1bd1ef scavenge_mutable_list (/nix/store/59ng7169ncp4g0xcyxdmd5bf5gd9yilm-ghc-9.6.1/lib/ghc-9.6.1/lib/x86_64-linux-ghc-9.6.1/libHSrts-1.0.2_thr-ghc9.6.1.so)
> 0x7fffef1bd420 scavenge_capability_mut_lists (/nix/store/59ng7169ncp4g0xcyxdmd5bf5gd9yilm-ghc-9.6.1/lib/ghc-9.6.1/lib/x86_64-linux-ghc-9.6.1/libHSrts-1.0.2_thr-ghc9.6.1.so)
> 0x7fffef1b322a GarbageCollect (/nix/store/59ng7169ncp4g0xcyxdmd5bf5gd9yilm-ghc-9.6.1/lib/ghc-9.6.1/lib/x86_64-linux-ghc-9.6.1/libHSrts-1.0.2_thr-ghc9.6.1.so)
> 0x7fffef193fdd scheduleDoGC (/nix/store/59ng7169ncp4g0xcyxdmd5bf5gd9yilm-ghc-9.6.1/lib/ghc-9.6.1/lib/x86_64-linux-ghc-9.6.1/libHSrts-1.0.2_thr-ghc9.6.1.so)
> 0x7fffef194c02 schedule (/nix/store/59ng7169ncp4g0xcyxdmd5bf5gd9yilm-ghc-9.6.1/lib/ghc-9.6.1/lib/x86_64-linux-ghc-9.6.1/libHSrts-1.0.2_thr-ghc9.6.1.so)
> 0x7fffef19585c scheduleWorker (/nix/store/59ng7169ncp4g0xcyxdmd5bf5gd9yilm-ghc-9.6.1/lib/ghc-9.6.1/lib/x86_64-linux-ghc-9.6.1/libHSrts-1.0.2_thr-ghc9.6.1.so)
> 0x7fffef199edd workerStart (/nix/store/59ng7169ncp4g0xcyxdmd5bf5gd9yilm-ghc-9.6.1/lib/ghc-9.6.1/lib/x86_64-linux-ghc-9.6.1/libHSrts-1.0.2_thr-ghc9.6.1.so)
> 0x7fffeeed2e24 start_thread (/nix/store/1n2l5law9g3b77hcfyp50vrhhssbrj5g-glibc-2.37-8/lib/libc.so.6)
> 0x7fffeef549b0 __clone3 (/nix/store/1n2l5law9g3b77hcfyp50vrhhssbrj5g-glibc-2.37-8/lib/libc.so.6)
>
> (GHC version 9.6.1 for x86_64_unknown_linux)
> Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
> /nix/store/5s1yg5l36wzgy1dj0vv1ibarc4g7vrdr-stdenv-linux/setup: line 1595: 103601 Aborted (core dumped) ./Setup build
```9.6.2Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/23374Segfault on RTS schedule function (GHC 9.6.1)2023-10-18T17:02:42ZIan-Woo KimSegfault on RTS schedule function (GHC 9.6.1)We consistently have segfault on a specific location of RTS `schedule` on macos M1 laptops.
On my machine (macos 13.2.1), I was able to get a core dump of the crash (happened once):
```
* thread #28, stop reason = ESR_EC_PC_ALIGN (fault ...We consistently have segfault on a specific location of RTS `schedule` on macos M1 laptops.
On my machine (macos 13.2.1), I was able to get a core dump of the crash (happened once):
```
* thread #28, stop reason = ESR_EC_PC_ALIGN (fault address: 0xf9400291910006d6)
* frame #0: 0x00000011910006d6
frame #1: 0x00000001035a4b04 libHSrts-1.0.2_thr-ghc9.6.1.dylib`schedule + 1188
```
On my colleague's machine, it was much more frequent (on macos 13.3.1) and from ~/Library/Logs/DiagnosticReports, we were able to get some OS reports:
```
Thread 31 Crashed:: ghc_worker
1 ??? 0x1057f0b04 schedule + 1188
```
```
Thread 53 Crashed:: ghc_worker
0 ??? 0x702a03daa1 ???
1 ??? 0x1033ecb04 schedule + 1188
2 libsystem_pthread.dylib 0x19ad16da0 thread_start + 8
```
```
Thread 33 Crashed:: ghc_worker
0 ??? 0x35c60 ???
1 ??? 0x105bfcb04 schedule + 1188
2 libsystem_pthread.dylib 0x19ad16da0 thread_start + 8
```
We use the same GHC binary from our nix setup, so the crash happened at the same location.Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/23371GHC enters endless loop in ghc 9.4 (fixed in ghc >= 9.6)2023-05-16T14:29:27ZMagnus ViernickelGHC enters endless loop in ghc 9.4 (fixed in ghc >= 9.6)## Summary
I was playing around with some constraints stuff and encountered a weird thing where the compiler (apparently) enters an endless loop when trying to add a `Show` instance. This is indeed an erroneous program, but I still don'...## Summary
I was playing around with some constraints stuff and encountered a weird thing where the compiler (apparently) enters an endless loop when trying to add a `Show` instance. This is indeed an erroneous program, but I still don't want the compiler enters an endless loop.
I hope this is no duplicate (didn't quite read through all 1000 issues that contain "loop")
## Steps to reproduce
```haskell
{-# LANGUAGE BlockArguments #-}
{-# LANGUAGE DerivingVia #-}
{-# LANGUAGE FunctionalDependencies #-}
{-# LANGUAGE TypeFamilies #-}
{-# OPTIONS_GHC -Wall #-}
module Has where
import Data.Functor.Identity (Identity (Identity))
import Data.Kind (Constraint, Type)
type Has :: forall k. (k -> Constraint) -> (k -> Type) -> k -> Type
data Has c f a where
Proves :: c a => f a -> Has c f a
type Top :: forall k. k -> Constraint
class Top a
instance Top a
class CFunctor c f | f -> c where
cfmap :: c b => (a -> b) -> f a -> (c b => f b -> r) -> r
instance CFunctor c (Has (c :: Type -> Constraint) f) where
cfmap f x k = k $ Proves (cfmap f x \(Proves y) -> y)
newtype Unconstrained f a = MkUnconstrained {getFunctor :: f a}
instance Functor f => CFunctor Top (Unconstrained f) where
cfmap f x k = k $ MkUnconstrained (f <$> getFunctor x)
deriving via (Unconstrained Identity) instance CFunctor Top Identity
-- instance Show (Has c f a) where
-- show = cfmap show
```
comment out the last two lines, ghci should hang
## Expected behavior
The compiler terminates.
## Environment
* GHC version used: 945
Optional:
- system: `"x86_64-linux"`
- host os: `Linux 6.3.1-zen1, NixOS, 23.05 (Stoat), 23.05.20230506.897876e`
## Additional information
- the issue does not occur with 961
- commenting out TypeFamilies causes a warning to be show by the `deriving via` declaration9.4.6sheafsam.derbyshire@gmail.comsheafsam.derbyshire@gmail.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/23341Bump terminfo2023-05-09T14:16:28ZBen GamariBump terminfoOn IRC @jade reported that GHC `master` failed to build on x86-64/Arch Linux using the `dash` shell due to `terminfo`'s `configure` script. The bug is fixed in https://github.com/judah/terminfo/pull/54. We should make sure this gets merg...On IRC @jade reported that GHC `master` failed to build on x86-64/Arch Linux using the `dash` shell due to `terminfo`'s `configure` script. The bug is fixed in https://github.com/judah/terminfo/pull/54. We should make sure this gets merged and bump the submodule.9.6.2https://gitlab.haskell.org/ghc/ghc/-/issues/23309On Windows (only), with GHC 9.6.1 and 9.4.5, seeing linker errors in some cases2023-10-12T10:48:42ZMike PilgremOn Windows (only), with GHC 9.6.1 and 9.4.5, seeing linker errors in some cases## Summary
On Windows (only), with GHC 9.6.1 and GHC 9.4.5, with (it seems) both Cabal (the tool) and Stack (which depends on Cabal (the library), both as part of CI and local builds, errors similar to the following are being reported d...## Summary
On Windows (only), with GHC 9.6.1 and GHC 9.4.5, with (it seems) both Cabal (the tool) and Stack (which depends on Cabal (the library), both as part of CI and local builds, errors similar to the following are being reported during the linking part of building some packages - the signature is a rash of complaints about 'unknown symbol':
~~~
❯ stack --stack-yaml stack-ghc-9.4.5.yaml build
pantry> configure (lib)
Configuring pantry-0.8.2.1...
pantry> build (lib)
Preprocessing library for pantry-0.8.2.1..
Building library for pantry-0.8.2.1..
[ 1 of 19] Compiling Pantry.Internal.AesonExtended
[ 2 of 19] Compiling Pantry.Internal.Companion
...
[18 of 19] Compiling Pantry.Repo
[19 of 19] Compiling Pantry
ghc-9.4.5.exe: | C:\sr\snapshots\0f744d27\lib\x86_64-windows-ghc-9.4.5\network-3.1.2.8-DIslA85FC627S0eMFb26Fp\libHSnetwork-3.1.2.8-DIslA85FC627S0eMFb26Fp.a: unknown symbol `__mingw_vsprintf'
ghc-9.4.5.exe: | C:\sr\snapshots\0f744d27\lib\x86_64-windows-ghc-9.4.5\network-3.1.2.8-DIslA85FC627S0eMFb26Fp\libHSnetwork-3.1.2.8-DIslA85FC627S0eMFb26Fp.a: unknown symbol `getWSErrorDescr'
ghc-9.4.5.exe: | C:\sr\snapshots\0f744d27\lib\x86_64-windows-ghc-9.4.5\network-3.1.2.8-DIslA85FC627S0eMFb26Fp\libHSnetwork-3.1.2.8-DIslA85FC627S0eMFb26Fp.a: unknown symbol `networkzm3zi1zi2zi8zmDIslA85FC627S0eMFb26Fp_NetworkziSocketziInternal_withSocketsInit_closure'
ghc-9.4.5.exe: | C:\sr\snapshots\0f744d27\lib\x86_64-windows-ghc-9.4.5\network-3.1.2.8-DIslA85FC627S0eMFb26Fp\libHSnetwork-3.1.2.8-DIslA85FC627S0eMFb26Fp.a: unknown symbol `networkzm3zi1zi2zi8zmDIslA85FC627S0eMFb26Fp_NetworkziSocketziBuffer_zdwsendBuf_closure'
ghc-9.4.5.exe: | C:\sr\snapshots\0f744d27\lib\x86_64-windows-ghc-9.4.5\tls-1.6.0-L7vOrX5PXtxCYn6XOlo0lf\libHStls-1.6.0-L7vOrX5PXtxCYn6XOlo0lf.a: unknown symbol `networkzm3zi1zi2zi8zmDIslA85FC627S0eMFb26Fp_NetworkziSocketziByteStringziIO_zdwrecv_closure'
ghc-9.4.5.exe: | C:\sr\snapshots\0f744d27\lib\x86_64-windows-ghc-9.4.5\tls-1.6.0-L7vOrX5PXtxCYn6XOlo0lf\libHStls-1.6.0-L7vOrX5PXtxCYn6XOlo0lf.a: unknown symbol `tlszm1zi6zi0zmL7vOrX5PXtxCYn6XOlo0lf_NetworkziTLSziBackend_zdtcBackend_closure'
ghc-9.4.5.exe: | C:\sr\snapshots\0f744d27\lib\x86_64-windows-ghc-9.4.5\connection-0.3.1-6Q8NoORXRD3cfhY8fQImM\libHSconnection-0.3.1-6Q8NoORXRD3cfhY8fQImM.a: unknown symbol `tlszm1zi6zi0zmL7vOrX5PXtxCYn6XOlo0lf_NetworkziTLSziContextziInternal_zdtcContext_closure'
ghc-9.4.5.exe: | C:\sr\snapshots\0f744d27\lib\x86_64-windows-ghc-9.4.5\http-client-tls-0.3.6.1-1irORuvOSZS7lk0vW4RHCH\libHShttp-client-tls-0.3.6.1-1irORuvOSZS7lk0vW4RHCH.a: unknown symbol `connectionzm0zi3zi1zm6Q8NoORXRD3cfhY8fQImM_NetworkziConnectionziTypes_SockSettingsSimple_con_info'
ghc-9.4.5.exe: | C:\sr\snapshots\0f744d27\lib\x86_64-windows-ghc-9.4.5\casa-client-0.0.1-CluYGfz85ea6VJMUkpqtF2\libHScasa-client-0.0.1-CluYGfz85ea6VJMUkpqtF2.a: unknown symbol `httpzmclientzmtlszm0zi3zi6zi1zm1irORuvOSZZS7lk0vW4RHCH_NetworkziHTTPziClientziTLS_globalManager_closure'
ghc-9.4.5.exe: ^^ Could not load 'casazmclientzm0zi0zi1zmCluYGfzz85ea6VJMUkpqtF2_CasaziClient_thParserCasaRepo_closure', dependency unresolved. See top entry above.
<no location info>: error:
GHC.ByteCode.Linker.lookupCE
During interactive linking, GHCi couldn't find the following symbol:
casazmclientzm0zi0zi1zmCluYGfzz85ea6VJMUkpqtF2_CasaziClient_thParserCasaRepo_closure
This may be due to you not asking GHCi to load extra object files,
archives or DLLs needed by your current session. Restart GHCi, specifying
the missing library using the -L/path/to/object/dir and -lmissinglibname
flags, or simply by naming the relevant files on the GHCi command line.
Alternatively, this link failure might indicate a bug in GHCi.
If you suspect the latter, please report this as a GHC bug:
https://www.haskell.org/ghc/reportabug
Error: [S-7282]
Stack failed to execute the build plan.
While executing the build plan, Stack encountered the error:
[S-7011]
While building package pantry-0.8.2.1 (scroll up to its section to see the error) using:
C:\sr\setup-exe-cache\x86_64-windows\Cabal-simple_sDt42OhJ_3.8.1.0_ghc-9.4.5.exe --verbose=1 --builddir=.stack-work\dist\22605e11 build lib:pantry --ghc-options " -fdiagnostics-color=always"
Process exited with code: ExitFailure 1
~~~
The example above is for building `pantry` with Stack and GHC 9.4.5 (see: https://github.com/commercialhaskell/pantry/issues/85) but other instances of this phenomenon include:
* the `Cabal` repository: https://github.com/haskell/cabal/issues/8858
* the `hpack` repository: https://github.com/sol/hpack/pull/548
* the `hakyll`: https://github.com/jaspervdj/hakyll/issues/986
Given the references to the `network` package, I raised an issue here: https://github.com/haskell/network/issues/544 but the maintainer there did not recognise the issue as being `network`-related (or GHC-related). I don't know that the issue is GHC-related, but I am hoping the experts here may have some idea.
The `network` package itself builds without problem. This seems to be something to do with depending on the package.
## Steps to reproduce
Move the build of an affected package from GHC 9.4.4 to GHC 9.4.5 or GHC 9.6.1, and then attempt to build.
## Environment
* GHC 9.4.5 (not GHC 9.4.4); GHC 9.6.1.
Optional:
* Operating System: Windowshttps://gitlab.haskell.org/ghc/ghc/-/issues/23269CI job "abi-test-nightly" is broken2023-05-08T16:21:39ZBryan Rbryan@haskell.foundationCI job "abi-test-nightly" is brokenThis job tries to untar a file `ghc-x86_64-linux-fedora33-release-hackage_docs.tar.xz`, but it doesn't exist.
The job depends on two previous jobs, "nightly-x86_64-linux-fedora33-release-hackage" and "nightly-x86_64-linux-fedora33-relea...This job tries to untar a file `ghc-x86_64-linux-fedora33-release-hackage_docs.tar.xz`, but it doesn't exist.
The job depends on two previous jobs, "nightly-x86_64-linux-fedora33-release-hackage" and "nightly-x86_64-linux-fedora33-release", but apparently neither of them have that file in their artifacts.
This job has never succeeded. :)Bryan Rbryan@haskell.foundationBryan Rbryan@haskell.foundationhttps://gitlab.haskell.org/ghc/ghc/-/issues/23217Test of atomic fetches fails on i386 with allocateRegsAndSpill panic2023-04-05T16:12:10ZBodigrimTest of atomic fetches fails on i386 with allocateRegsAndSpill panicAn i386 job for !10228 (https://gitlab.haskell.org/ghc/ghc/-/jobs/1435453#L4752) fails with:
```
Compile failed (exit code 1) errors were:
ghc-9.7.20230402: panic! (the 'impossible' happened)
GHC version 9.7.20230402:
allocateRegsAndS...An i386 job for !10228 (https://gitlab.haskell.org/ghc/ghc/-/jobs/1435453#L4752) fails with:
```
Compile failed (exit code 1) errors were:
ghc-9.7.20230402: panic! (the 'impossible' happened)
GHC version 9.7.20230402:
allocateRegsAndSpill: Cannot read from uninitialized register
%vHi_H3
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/GHC/Utils/Panic.hs:189:37 in ghc:GHC.Utils.Panic
pprPanic, called at compiler/GHC/CmmToAsm/Reg/Linear.hs:837:20 in ghc:GHC.CmmToAsm.Reg.Linear
CallStack (from HasCallStack):
panic, called at compiler/GHC/Utils/Error.hs:480:29 in ghc:GHC.Utils.Error
```
`GHC.CmmToAsm.Reg.Linear` says
```haskell
pprPanic "allocateRegsAndSpill: Cannot read from uninitialized register" (ppr r)
-- NOTE: if the input to the NCG contains some
-- unreachable blocks with junk code, this panic
-- might be triggered. Make sure you only feed
-- sensible code into the NCG. In GHC.Cmm.Pipeline we
-- call removeUnreachableBlocks at the end for this
-- reason.
```
This might be very well the case: !10228 adds a test case with hand-written CMM. However, while the code in question is silly, up to my (very limited) understanding all blocks should be reachable. And all 64-bit jobs succeed.
This is not a blocker for !10228 (#23206) which is concerned only with adding `%fetch_fooXX` primops to CMM parser. I'm going to disable i386 job there.Andreas KlebingerAndreas Klebingerhttps://gitlab.haskell.org/ghc/ghc/-/issues/23194Likely bug under Windows with mimimal reproducer2023-04-05T19:33:01ZdsamperiLikely bug under Windows with mimimal reproducer## Summary
Write a brief description of the issue.
For a mimimal FFI interface to R, values fetched from R in a library installed by
stack (compiled with ghc) are corrupted under Windows, while if everything (including the library
modu...## Summary
Write a brief description of the issue.
For a mimimal FFI interface to R, values fetched from R in a library installed by
stack (compiled with ghc) are corrupted under Windows, while if everything (including the library
module) is compiled with ghci there are no problems. A function in R.dll is called
successfully before attempting to read one of the corrupted variables, so this does
not seem to be a problem with delayed loading of the library, or relocation of the
library. There are no problems under Ubuntu Linux.
## Steps to reproduce
This Haskell package is a minimal reproducer (all unrelated code has been
stripped out of the hR package).
[hRbug-0.2.0.tar.gz](/uploads/492667c4739527065403b0636583bd6d/hRbug-0.2.0.tar.gz)
To install under Windows, be sure that R is in PATH, and that a UNIX/MSYS shell
is also in PATH (from Stack or Rtools). Then type 'stack install'
Setup.hs looks for R in PATH to do most of the configuration. As part of the setup the
script runhr is written to ~/.local/bin, which should be added to PATH.
There are two source files, a client (app/embeddedR.hs) and a library
(Rinternals/InternalsNilValue.hs). The client creates an embedded R instance,
calls a function in R.dll, and tries to read rNilValue, a variable that is
bound to R_NilValue in the library.
To run the app using the library that was installed
by stack, use 'stack exec embeddedR'. This will result in
a crash under Windows because rNilValue is not valid.
On the other hand, to compile everything (including the library) using ghci
use 'runhr app\embeddedR.hs'. Then start the app by running main. Everything
should work fine in this case.
Sometimes (not always) placing a trace like 'trace "PEEK"' before the peek in
InternalsNilValue.hs resolves the problem, perhaps because this changes the
exeuction order in some way.
## Expected behavior
The app should behave the same when compiled using ghc or ghci.
## Environment
* GHC version used: 9.2.7
Optional:
* Operating System: Windows 11
* System Architecture: Intel i9Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/23185Soundness of thunk update?2024-02-19T08:23:52ZBen GamariSoundness of thunk update?I am beginning to have second thoughts on whether the thunk update protocol we currently use (see `Note [Heap memory barriers]` in `SMP.h`) is safe on weakly ordered platforms. The problem is that lazy blackholing may mean that multiple ...I am beginning to have second thoughts on whether the thunk update protocol we currently use (see `Note [Heap memory barriers]` in `SMP.h`) is safe on weakly ordered platforms. The problem is that lazy blackholing may mean that multiple threads race to update a thunk, resulting in a value being exposed via an indirection before being made available to other cores.
Specifically, I am worried about interleavings like the following (where `t` is a thunk being updated and `a` and `b` are two evaluation results):
```
Thread A Thread B Thread C
--------- --------- ---------
t.indirectee=a
t.indirectee=b
release fence
t.info=BLACKHOLE
read t.info
inspect t.indirectee
release fence
t.info=BLACKHOLE
```
Specifically, we see here that Thread A writes its result, `a` to the indirectee. Typically, the soundness of the update of the `indirectee` field is guaranteed by the release ordering of the `t.info=BLACKHOLE` store, guaranteeing that `a` is visible to readers when the closure becomes a blackhole.
However, in this case Thread B races to update `indirectee`, storing its own result `b`. Meanwhile, thread `C` enters `t` (which is now a blackhole), inspects `t.indirectee`, and is therefore exposed to `b` before Thread B has guaranteed that it is visible.
This seems like an extrodinarily narrow race, but AFAICT it's a race nevertheless.Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/23182`DontRetainCAFs` for updating results in segmentation faults2023-04-17T10:07:44ZJonathan Watson`DontRetainCAFs` for updating results in segmentation faults## Summary
I have been trying to add unloading support to my dynamic software updating system by using the `DontRetainCAFs` option for GHCi's object code linker, but this often resulting in crashes.
My DSU system uses GHC's API in a si...## Summary
I have been trying to add unloading support to my dynamic software updating system by using the `DontRetainCAFs` option for GHCi's object code linker, but this often resulting in crashes.
My DSU system uses GHC's API in a similar way to GHCi in order to load in different versions of programs. This works well, but performing many updates will result in the memory usage increasing, as GHC's garbage collector will not unload Haskell object files that GHC's runtime loader has linked under normal conditions. This is a result of `initObjLinker` being given the `RetainCAFs` option. To add unloading support, my DSU system can now instead use the `DontRetainCAFs` option. This gives the desired behaviour, but sometimes segmentation faults and other crashes can occur before the DSU system has even requested that an object file is unloaded.
To debug this, I have created a branch of my project's repository containing two versions of a very simple program. It also contains a demo executable that updates the first version of program to the next version, with unloading enabled. When I run this demo with a very small nursery size, a segmentation fault reliably occurs. This does not occur when unloading is not enabled. Due to the design of my DSU system, the only difference that enabling unloading makes in this situation is using `DontRetainCAFs`. In this demo, I also give every package (including external packages, using Cabal/Stack) the following flags: `-rdynamic -fwhole-archive-hs-libs -fkeep-cafs`. Most of these flags can also be found in a [Cabal file in `ghc-hotswap`](https://github.com/fbsamples/ghc-hotswap/blob/0c2859cbbc6c8708eace3087ab163db2b6648d4c/ghc-hotswap-demo/ghc-hotswap-demo.cabal), described in ["Hotswapping Haskell" by Jon Coens](http://simonmar.github.io/posts/2017-10-17-hotswapping-haskell.html).
- `-fwhole-archive-hs-libs` and `-rdynamic` ensure that all Haskell symbol files are exported by object files such that they can be used by arbitrarily loaded object files.
- `fkeep-cafs` stops CAFs being garbage collected. This should achieve the same effect as [`HotswapMain.c` in `ghc-hotswap`](https://github.com/fbsamples/ghc-hotswap/blob/0c2859cbbc6c8708eace3087ab163db2b6648d4c/ghc-hotswap-demo/HotswapMain.c). It feels like adding this option globally should result in changing `RetainCAFs` to `DontRetainCAFs` having no effect, but this is not happening.
Most of the relevant code is found in [`lowarn-runtime`'s `Linker` module](https://github.com/jonathanjameswatson/lowarn/blob/701a53c0a63b54026499011c99a9a3612d15f972/runtime/src/Lowarn/Linker.hs). In my demo, `load` is called twice. Enabling unloading does not change the sets of loaded or unloaded object files in this case, as the second set of object files that are loaded is a superset of the first.
I have been struggling to figure out what the exact cause of the issue is for a while. Perhaps my understanding of CAFs is flawed and my approach to unloading is impossible, but I feel something must be correct, as my method does keep the memory usage of successive updates eventually constant when it doesn't run into segmentation faults. However, I have been unable to determine any way to reliably avoid these segmentation faults.
## Steps to reproduce
Clone the `reproduction` branch of this repository: https://github.com/jonathanjameswatson/lowarn/tree/reproduction and use either Stack or Cabal:
**Stack**
1. `stack build`
2. `stack exec reproduction-exe`
**Cabal**
1. `cabal build all`
2. `LOWARN_PACKAGE_ENV=$(realpath .ghc.environment*) cabal run reproduction-exe`
In either case, the nursery size can be minimised by adding `+RTS -A8k -RTS` to the end of the command (and `--` before `reproduction-exe`).
There seem to be many errors that can be given, including a segmentation fault.
## Expected behavior
[Version 1](https://github.com/jonathanjameswatson/lowarn/tree/701a53c0a63b54026499011c99a9a3612d15f972/examples/reproduction/versions/1.0.0) of the program is linked in, immediately starts, and then ends, passing the state `"a"` to the next version of the program.
[The update](https://github.com/jonathanjameswatson/lowarn/tree/701a53c0a63b54026499011c99a9a3612d15f972/examples/reproduction/updates/1.0.0-2.0.0) is linked in and applied. This converts the old types to the new types. [Version 2](https://github.com/jonathanjameswatson/lowarn/tree/701a53c0a63b54026499011c99a9a3612d15f972/examples/reproduction/versions/2.0.0), included in the update package, starts with the new state, and does not crash.
This behaviour can be given by changing [line 34 of the main file of the demo's executable](https://github.com/jonathanjameswatson/lowarn/blob/701a53c0a63b54026499011c99a9a3612d15f972/examples/reproduction/demo/app/Main.hs) to `runRuntime runtime True`, disabling unloading.
## Environment
* GHC version used: 9.2.7
Optional:
* Operating System: Ubuntu 20.04.4 LTS on WSL2 for Windows 11
* System Architecture: AMD64Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/23180Fix memory ordering of ghc-heap2023-03-25T16:27:01ZBen GamariFix memory ordering of ghc-heap`ghc-heap` currently makes no attempt to ensure that heap object accesses are concurrency safe. We need to address this.`ghc-heap` currently makes no attempt to ensure that heap object accesses are concurrency safe. We need to address this.Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/23166NumDecimals detection of integral literals is broken2023-11-24T14:34:16ZMerijn VerstraatenNumDecimals detection of integral literals is broken## Summary
According to the documentation of `NumDecimals` any integral literal in scientific notation will desugar into using `fromInteger`, rather than `fromRational`. However, the logic for detecting whether a literal is integral see...## Summary
According to the documentation of `NumDecimals` any integral literal in scientific notation will desugar into using `fromInteger`, rather than `fromRational`. However, the logic for detecting whether a literal is integral seems to be broken. This seems to (mostly?) affect literals with large exponents.
## Steps to reproduce
Enable `-XNumDecimals` in ghc or ghci, compile any code including `(1e101 :: Integer)`. This produces a type error:
``` • No instance for (Fractional Integer) arising from the literal ‘1e101’```
Confusingly, `(10e100 :: Integer)` works just fine, despite evaluating to the same value.
## Expected behavior
This should compile without error.
## Environment
* GHC version used: 9.2, 9.4, and 9.6 (possibly far earlier to, but I didn't test)
Optional:
* Operating System:
* System Architecture:https://gitlab.haskell.org/ghc/ghc/-/issues/23160Segfault during nonmoving marking of weak ptrs (GHC-9.2.6)2024-03-05T10:04:45ZTeo CamarasuSegfault during nonmoving marking of weak ptrs (GHC-9.2.6)## Summary
We've been running into some segfaults while using the non-moving gc with GHC-9.2.6 in production recently.
Here is a back trace:
```
#0 mark_closure (queue=queue@entry=0x7f2340016e70, p0=0x4d5497fc51, origin=origin@entry=0x...## Summary
We've been running into some segfaults while using the non-moving gc with GHC-9.2.6 in production recently.
Here is a back trace:
```
#0 mark_closure (queue=queue@entry=0x7f2340016e70, p0=0x4d5497fc51, origin=origin@entry=0x0) at rts/sm/NonMovingMark.c:1427
#1 0x0000000000417473 in nonmovingMark (budget=budget@entry=0x7f1f4d7f9c68, queue=queue@entry=0x7f2340016e70) at rts/sm/NonMovingMark.c:1762
#2 0x000000000b4d0a1c in nonmovingMarkThreadsWeaks (budget=budget@entry=0x7f1f4d7f9c68, mark_queue=mark_queue@entry=0x7f2340016e70) at rts/sm/NonMoving.c:1024
#3 0x000000000b4d0afd in nonmovingMark_ (mark_queue=0x7f2340016e70, dead_weaks=dead_weaks@entry=0x7f1f4d7f9ca0, resurrected_threads=resurrected_threads@entry=0x7f1f4d7f9ca8)
at rts/sm/NonMoving.c:1099
#4 0x000000000b4d0dc2 in nonmovingConcurrentMark (data=<optimized out>) at rts/sm/NonMoving.c:1044
#5 0x00007f23a381e609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#6 0x00007f23a352f133 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
```
As far as I can tell from this and poking around in gdb, at some point during the marking of weak pointers, a rubbish closure gets put on the mark queue.
This is probably related to the fixes for #22264
As our codebase is proprietary and this has only happened so far in production. It will be tricky to extract a reproducer.
In the meantime if there's any information you'd like us to extract from the core dumps do let us know.
## Environment
* GHC version used: GHC-9.2.6
Optional:
* Operating System: Ubuntu
* System Architecture: x86_64-linux9.6.2Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/23156GHC version 9.4.4: heap overflow; the same with 9.6.1, but 9.2.7 compiles fine2023-07-03T09:33:13ZMikolaj KonarskiGHC version 9.4.4: heap overflow; the same with 9.6.1, but 9.2.7 compiles fine## Summary
Heap overflow when compiling, both with -O0 and with -O1.
Edit: Disclaimer: lots of `UndecidableInstances` in this code, though not in the file on which GHC diverges.
## Steps to reproduce
Clone this repo at this commit
h...## Summary
Heap overflow when compiling, both with -O0 and with -O1.
Edit: Disclaimer: lots of `UndecidableInstances` in this code, though not in the file on which GHC diverges.
## Steps to reproduce
Clone this repo at this commit
https://github.com/Mikolaj/horde-ad/commit/773bc01382748b073fddee776b6fd8e6657c35df
then run (you can ignore `cabal.project`, the fork of `mnist-idx` is no longer needed)
`cabal build -j1 --disable-optimization`
Or any other `build` invocation. I haven't found a set of options for which it does compile.
## Expected behavior
Compiles.
## Environment
Fails the same with 9.4.4 and 9.6.1 (with `--allow-newer`). Fails the same in CI:
https://github.com/Mikolaj/horde-ad/actions/runs/4492044812/jobs/7901371200#step:18:629
Compiles and all tests pass with 9.2.7.Simon Peyton JonesSimon Peyton Jones