GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2023-09-07T09:41:40Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/23899Nightly primops test failed on Darwin2023-09-07T09:41:40ZBryan Rbryan@haskell.foundationNightly primops test failed on DarwinJob [#1649852](https://gitlab.haskell.org/ghc/test-primops/-/jobs/1649852) failed for test-primops@e7d5ce0be2f2a56fc2103ae3d2267101fcfc8f7f
Via nightly pipeline https://gitlab.haskell.org/ghc/ghc/-/pipelines/83410Job [#1649852](https://gitlab.haskell.org/ghc/test-primops/-/jobs/1649852) failed for test-primops@e7d5ce0be2f2a56fc2103ae3d2267101fcfc8f7f
Via nightly pipeline https://gitlab.haskell.org/ghc/ghc/-/pipelines/834109.8.2Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/23898ghc-heap: Stack.cmm and Stack.c clash when building with Cabal2023-08-29T20:41:58Zhamishmackghc-heap: Stack.cmm and Stack.c clash when building with Cabal## Summary
When built with Cabal `libraries/ghc-heap/cbits/Stack.c` and `libraries/ghc-heap/cbits/Stack.cmm` clash (the object files for both are written to `dist/build/cbits/Stack.o`).
@hsyl20 mentioned that apparently hadrian puts ar...## Summary
When built with Cabal `libraries/ghc-heap/cbits/Stack.c` and `libraries/ghc-heap/cbits/Stack.cmm` clash (the object files for both are written to `dist/build/cbits/Stack.o`).
@hsyl20 mentioned that apparently hadrian puts artifacts in `.../build/{c,cmm,s,...}/....` (avoiding the clash of names).
## Steps to reproduce
Use a `Cabal` based builder to build the `ghc-heap` package.
## Possible Fix
Rename one of the files so that `Cabal` does not try to build both of them as `Stack.o`.9.8.1Sylvain HenrySylvain Henryhttps://gitlab.haskell.org/ghc/ghc/-/issues/23819Release tracking ticket for GHC 9.4.72023-09-12T13:51:12ZBen GamariRelease tracking ticket for GHC 9.4.7This is the release checklist for the %9.4.7 milestone. See #16816 for the template that this was derived from.
# Pre-release checklist
* [x] Ensure that submodules are on released tags (the below is produced using [this script](https...This is the release checklist for the %9.4.7 milestone. See #16816 for the template that this was derived from.
# Pre-release checklist
* [x] Ensure that submodules are on released tags (the below is produced using [this script](https://gitlab.haskell.org/bgamari/ghc-utils/blob/master/rel-eng/submod-release-summary.py)):
* [ ] `libraries/Cabal`: version *todo*
* [ ] `libraries/Win32`: version *todo*
* [ ] `libraries/binary`: version *todo*
* [ ] `libraries/bytestring`: version *todo*
* [ ] `libraries/containers`: version *todo*
* [ ] `libraries/deepseq`: version *todo*
* [ ] `libraries/directory`: version *todo*
* [ ] `libraries/filepath`: version *todo*
* [ ] `libraries/haskeline`: version *todo*
* [ ] `libraries/mtl`: version *todo*
* [ ] `libraries/parsec`: version *todo*
* [ ] `libraries/pretty`: version *todo*
* [ ] `libraries/process`: version *todo*
* [ ] `libraries/terminfo`: version *todo*
* [ ] `libraries/text`: version *todo*
* [ ] `libraries/time`: version *todo*
* [ ] `libraries/transformers`: version *todo*
* [ ] `libraries/unix`: version *todo*
* [ ] `libraries/xhtml`: version *todo*
* [ ] `utils/haddock`: version *todo*
* [ ] `utils/hsc2hs`: version *todo*
* [x] Notify stakeholders of release progress: `Julian Ospald <hasufell@posteo.de>, ghc-devs@haskell.org`
* [x] Non-released submodules up-to-date:
* [ ] `nofib` (upstream: ghc/nofib>)
* [ ] `libffi-tarballs` (upstream: ghc/libffi-tarballs>)
* [ ] `libraries/ghc-bignum/gmp/gmp-tarballs` (upstream: ghc/gmp-tarballs>)
* [x] Release notes (`docs/users_guide/x.y.z-notes.rst`) written
* [x] Release notes linked in `docs/users_guide/release-notes.rst`
* [x] `autoconf` scripts [updated](https://gitlab.haskell.org/ghc/ghc/wikis/making-releases#updating-the-tree)
* [ ] [Update](https://gitlab.haskell.org/ghc/ghc/-/blob/master/hadrian/bootstrap/README.md) the Hadrian bootstrap metadata
* [x] Check that Unicode database in `base` (`libraries/base/cbits/README.Unicode`) reflects current standard release (http://www.unicode.org/versions/latest/).
* [x] `LlvmVersion` in `configure.ac` is targetting intended LLVM version
* [x] Release notes mentions LLVM version requirement
* [x] `llvm-targets` file [updated](https://gitlab.haskell.org/ghc/ghc/wikis/making-releases#updating-the-tree)
* [x] Changelogs updated (these can be checked using `.gitlab/linters/check-changelogs.sh`):
* [ ] `libraries/ghc-prim`
* [ ] `libraries/ghc-bignum`
* [ ] `libraries/template-haskell`
* [ ] `libraries/hpc` (upstream: ghc/hpc>)
* [ ] `libraries/base`
* [x] Verify that the ~"backport needed" label has no more issues/merge requests needing backport
* [x] Verify that all CI builds are green before moving to *release checklist*
* [x] Update hadrian bootstrap plans for the latest compiler releases:
* Update `hadrian/bootstrap/generate_bootstrap_plans` to include any new compiler releases in the last two major release series
* Drop any plans that are outside of the bootstrap support window
* Run `hadrian/bootstrap/generate_bootstrap_plans` and commit the files that it generates
* Update `bootstramp_matrix` in `.gitlab-ci.yml` to reflect the most recent minor release in each major series supported by bootstrapping
# Release checklist
* [ ] Ensure that the [Migration](https://gitlab.haskell.org/ghc/ghc/wikis/migration/) page is up-to-date
* [x] Push a provision provisional release commit to trigger the release builds using `git push -o ci.variable="RELEASE_JOB=yes"`
* [ ] Wait until builds finish; verify that they finished successfully
* [ ] Fetch release artifacts TODO: documentation
* [ ] Write down a link to the release pipeline here: <URL>
* [ ] Sign and push release artifacts to `downloads.haskell.org` [TODO: documentation]
* [ ] Submit `ghcup` metadata upstream:
* Download the `metadata_test.yaml` artifact from the `ghcup-metadata-release` job of the release pipeline
* Clone [`ghcup-metadata`](https://github.com/haskell/ghcup-metadata/)
* Integrate the appropriate release section (e.g. ``) into `ghcup-metadata/ghcup-0.0.7.yaml`
* Replace the `&id<n>` identifiers with unique names
* Open a merge request submitting the metadata upstream
* [ ] [Make a release tag](https://gitlab.haskell.org/ghc/ghc/wikis/making-releases#tagging-the-release)
* [ ] Release/revise GHC-maintained libraries on Hackage using [this script](https://gitlab.haskell.org/ghc/ghc/-/blob/master/.gitlab/upload_ghc_libs.py):
* [ ] `libraries/base`
* [ ] `libraries/ghc-prim`
* [ ] `libraries/array`
* [ ] `libraries/stm`
* [ ] `libraries/ghc-heap`
* [ ] `libraries/ghc-compact`
* [ ] `libraries/ghc-boot`
* [ ] `libraries/ghc-boot-th`
* [ ] `libraries/hpc`
* [ ] `libraries/libiserv`
* [ ] `libraries/template-haskell`
* [ ] `libraries/ghc-bignum`
* [ ] Update ghc/homepage>:
* [ ] Write download page (see ghc/homepage>)
* [ ] Make sure that the Signing Key is correct for the relevant release
* [ ] Add news item to [`index.html`](https://gitlab.haskell.org/ghc/homepage/blob/master/index.shtml)
* [ ] Add link to [`download.shtml`](https://gitlab.haskell.org/ghc/homepage/blob/master/download.shtml). Be sure to link to the Migration guide.
* [ ] Look over changes locally
* [ ] Add release announcement to [GHC blog](https://gitlab.haskell.org/ghc/homepage/tree/master/blog). Be sure to link to the Migration guide.
* [ ] Push changes to `master`
* [ ] Announce on: `GHC developers <ghc-devs@haskell.org>, GHC Users <glasgow-haskell-users@haskell.org>, Haskell Cafe <haskell-cafe@haskell.org>`
* [ ] Announce on: [Haskell Discourse](https://discourse.haskell.org/), [/r/haskell](https://reddit.com/r/haskell), [Twitter](https://twitter.com/)
* [ ] Update `latest` symlink on `downloads.haskell.org`
# Post-release checklist
* [ ] Update the Wiki [status page](https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-Status)
* [ ] Update the [language pragma history](https://gitlab.haskell.org/ghc/ghc/wikis/language-pragma-history)
* [ ] Mark milestone as *closed*
* [ ] Update `/topic` in `#ghc`
* [ ] Update the [VersionHistory](https://gitlab.haskell.org/ghc/ghc/wikis/commentary/libraries/version-history) wiki page
* [ ] Set `RELEASE=NO`
* [ ] Create a release tracking ticket for the next release using the template in #168169.4.7ZubinZubinhttps://gitlab.haskell.org/ghc/ghc/-/issues/23796TemplateHaskell typechecking regression in HEAD2023-08-08T13:08:41ZRyan ScottTemplateHaskell typechecking regression in HEAD_(Originally observed in a `head.hackage` CI job [here](https://gitlab.haskell.org/ghc/head.hackage/-/jobs/1632860).)_
The `what4-1.4` Hackage library currently fails to build with GHC HEAD + `head.hackage`. Here is a minimized example ..._(Originally observed in a `head.hackage` CI job [here](https://gitlab.haskell.org/ghc/head.hackage/-/jobs/1632860).)_
The `what4-1.4` Hackage library currently fails to build with GHC HEAD + `head.hackage`. Here is a minimized example of the issue:
```hs
{-# LANGUAGE RankNTypes #-}
{-# LANGUAGE TemplateHaskell #-}
module Bug where
good :: (forall a. a -> a) -> b -> b
good = \g x -> g x
bad :: (forall a. a -> a) -> b -> b
bad = $([| \g x -> g x |])
```
This compiles with GHC 9.8 and earlier, but fails to typecheck with GHC HEAD at commit b938950d98945f437f1e28b15a0a3629bfe336c2:
```
$ ghc-head Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:9:8: error: [GHC-83865]
• Couldn't match type: b -> b
with: forall a. a -> a
Expected: (forall a. a -> a) -> b -> b
Actual: (b -> b) -> b -> b
• In the expression: \ g_a24j x_a24k -> g_a24j x_a24k
In an equation for ‘bad’: bad = (\ g_a24j x_a24k -> g_a24j x_a24k)
• Relevant bindings include
bad :: (forall a. a -> a) -> b -> b (bound at Bug.hs:9:1)
|
9 | bad = $([| \g x -> g x |])
| ^^^^^^^^^^^^^^^^^^^
```
I think both of these should be accepted, as the only difference between `good` and `bad` is the presence of a Template Haskell splice.
While I haven't had time to bisect the issue just yet, my first hunch is to suspect commit !10911 (`Look through TH splices in splitHsApps`).9.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/23789error: unknown type name ‘clockid_t’ from bytestring bump2023-09-19T17:01:49ZJaro Reinderserror: unknown type name ‘clockid_t’ from bytestring bump@clyring the bytestring bump (https://gitlab.haskell.org/ghc/ghc/-/commit/43578d60bfc478e7277dcd892463cec305400025) causes my build to fail with:
```
from libraries/bytestring/cbits/is-valid-utf8.c:53:0: error:
/n...@clyring the bytestring bump (https://gitlab.haskell.org/ghc/ghc/-/commit/43578d60bfc478e7277dcd892463cec305400025) causes my build to fail with:
```
from libraries/bytestring/cbits/is-valid-utf8.c:53:0: error:
/nix/store/llmhxawhz6c4jqgjapbmsmz02579js0s-ghc-9.6.2-with-packages/lib/ghc-9.6.2/lib/x86_64-linux-ghc-9.6.2/rts-1.0.2/include/rts/OSThreads.h:38:5: error:
error: unknown type name ‘clockid_t’
38 | clockid_t timeout_clk;
| ^~~~~~~~~
|
38 | clockid_t timeout_clk;
| ^
`cc' failed in phase `C Compiler'. (Exit code: 1)
```
I can reproduce this on a clean build following the steps on ghc.dev:
```
git clone --recurse-submodules https://gitlab.haskell.org/ghc/ghc.git
git clone https://github.com/alpmestan/ghc.nix
nix develop ghc.nix
cd ghc
./boot && ./configure
hadrian/build -j
```
@alanz also reported seeing this issue on #ghc9.4.7ZubinZubinhttps://gitlab.haskell.org/ghc/ghc/-/issues/237889.8.0 binary-dist-dir creates name-ver-inplace library dirs2023-10-26T01:32:26ZJens Petersen9.8.0 binary-dist-dir creates name-ver-inplace library dirs## Summary
Previously (9.6 and earlier) with hadrian, core libraries were installed
in directories named name-version, but for 9.8.1-alpha1 there seems
to be a suffix added: my fedora build has `-inplace` appended
and I see short 4 char...## Summary
Previously (9.6 and earlier) with hadrian, core libraries were installed
in directories named name-version, but for 9.8.1-alpha1 there seems
to be a suffix added: my fedora build has `-inplace` appended
and I see short 4 char hashes in the upstream bindist (eg fedora33 build).
Grepping a bit didn't give me any real clues, what is going on...
## Steps to reproduce
`$ hadrian binary-dist-dir`
https://koji.fedoraproject.org/koji/taskinfo?taskID=104361497
https://koji.fedoraproject.org/koji/getfile?taskID=104361497&volume=DEFAULT&name=build.log&offset=-890000
## Expected behavior
No prefix?
## Environment
* GHC version used: 9.8.1-alpha1
Optional:
* Operating System: Fedora Linux
* System Architecture: x86_649.8.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/23723Tracking issue: Docker/gitlab-runner/golang incompatibility2023-11-03T10:23:01ZMatthew PickeringTracking issue: Docker/gitlab-runner/golang incompatibilityA breaking change in golang broke Docker (https://github.com/docker/cli/issues/4437#issuecomment-1637715017). It also broke gitlab-runner (https://gitlab.com/gitlab-org/gitlab-runner/-/issues/36051).
Until fixes for these problems flow ...A breaking change in golang broke Docker (https://github.com/docker/cli/issues/4437#issuecomment-1637715017). It also broke gitlab-runner (https://gitlab.com/gitlab-org/gitlab-runner/-/issues/36051).
Until fixes for these problems flow down the distribution channels, our gitlab runners are pinned to fixed versions of nixpkgs.
Original report follows.
- - - -
I have had to pause zw3rk linux runners 5,6 and 7.
ERROR: Job failed (system failure): prepare environment: http: invalid Host header (exec.go:71:0s). Check https://docs.gitlab.com/runner/shells/index.html#shell-profile-loading for more information
See: https://gitlab.haskell.org/ghc/ghc/-/jobs/1619718
cc @chreekat @angermanhttps://gitlab.haskell.org/ghc/ghc/-/issues/23691Some tests fail to terminate on Windows in release flavour2023-09-13T12:07:04ZBen GamariSome tests fail to terminate on Windows in release flavourStrange, a small selection of tests are failing to terminate on Windows when GHC is built in the `release+no_split_sections` flavour (`+no_split_sections` due to #22834 ). These include `ipeMap` and `linker_error1`. For instance,
```
$ ...Strange, a small selection of tests are failing to terminate on Windows when GHC is built in the `release+no_split_sections` flavour (`+no_split_sections` due to #22834 ). These include `ipeMap` and `linker_error1`. For instance,
```
$ _build/stage1/bin/ghc testsuite/tests/rts/ipe/ipeEventLog.c -no-hs-main -o ipeEventlog.exe testsuite/tests/rts/ipe/ipe_lib.c -threaded -debug
$ gdb --args ./ipeEventlog.exe
...
Thread 8 received signal SIGINT, Interrupt.
[Switching to Thread 17404.0x4064]
0x00007ffda1021a2d in TlsGetValue () from /c/WINDOWS/System32/KERNELBASE.dll
(gdb) thread apply all bt
Thread 8 (Thread 17404.0x4064):
#0 0x00007ffda1021a2d in TlsGetValue () from /c/WINDOWS/System32/KERNELBASE.dll
#1 0x00007ffda2907034 in KERNEL32!BaseThreadInitThunk () from /c/WINDOWS/System32/KERNEL32.DLL
#2 0x00007ffda3362651 in ntdll!RtlUserThreadStart () from /c/WINDOWS/SYSTEM32/ntdll.dll
#3 0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
Thread 6 (Thread 17404.0x2364):
#0 0x00007ffda33acdc4 in ntdll!ZwWaitForSingleObject () from /c/WINDOWS/SYSTEM32/ntdll.dll
#1 0x00007ffda0f81ace in WaitForSingleObjectEx () from /c/WINDOWS/System32/KERNELBASE.dll
#2 0x00007ff62eb27df4 in base_GHCziConcziPOSIX_zdwservicezuloop_info ()
#3 0x000001895a375870 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
Thread 5 (Thread 17404.0x5268):
#0 0x00007ffda33b0794 in ntdll!ZwWaitForWorkViaWorkerFactory () from /c/WINDOWS/SYSTEM32/ntdll.dll
#1 0x00007ffda3362dc7 in ntdll!TpReleaseCleanupGroupMembers () from /c/WINDOWS/SYSTEM32/ntdll.dll
#2 0x00007ffda2907034 in KERNEL32!BaseThreadInitThunk () from /c/WINDOWS/System32/KERNEL32.DLL
#3 0x00007ffda3362651 in ntdll!RtlUserThreadStart () from /c/WINDOWS/SYSTEM32/ntdll.dll
#4 0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
Thread 4 (Thread 17404.0x56ec):
#0 0x00007ffda33b0794 in ntdll!ZwWaitForWorkViaWorkerFactory () from /c/WINDOWS/SYSTEM32/ntdll.dll
#1 0x00007ffda3362dc7 in ntdll!TpReleaseCleanupGroupMembers () from /c/WINDOWS/SYSTEM32/ntdll.dll
#2 0x00007ffda2907034 in KERNEL32!BaseThreadInitThunk () from /c/WINDOWS/System32/KERNEL32.DLL
#3 0x00007ffda3362651 in ntdll!RtlUserThreadStart () from /c/WINDOWS/SYSTEM32/ntdll.dll
#4 0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
Thread 3 (Thread 17404.0x5578):
#0 0x00007ffda33b0794 in ntdll!ZwWaitForWorkViaWorkerFactory () from /c/WINDOWS/SYSTEM32/ntdll.dll
#1 0x00007ffda3362dc7 in ntdll!TpReleaseCleanupGroupMembers () from /c/WINDOWS/SYSTEM32/ntdll.dll
#2 0x00007ffda2907034 in KERNEL32!BaseThreadInitThunk () from /c/WINDOWS/System32/KERNEL32.DLL
#3 0x00007ffda3362651 in ntdll!RtlUserThreadStart () from /c/WINDOWS/SYSTEM32/ntdll.dll
#4 0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
Thread 2 (Thread 17404.0x5288):
#0 0x00007ffda33b0794 in ntdll!ZwWaitForWorkViaWorkerFactory () from /c/WINDOWS/SYSTEM32/ntdll.dll
#1 0x00007ffda3362dc7 in ntdll!TpReleaseCleanupGroupMembers () from /c/WINDOWS/SYSTEM32/ntdll.dll
#2 0x00007ffda2907034 in KERNEL32!BaseThreadInitThunk () from /c/WINDOWS/System32/KERNEL32.DLL
#3 0x00007ffda3362651 in ntdll!RtlUserThreadStart () from /c/WINDOWS/SYSTEM32/ntdll.dll
#4 0x0000000000000000 in ?? ()
--Type <RET> for more, q to quit, c to continue without paging--
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
Thread 1 (Thread 17404.0x38ac):
#0 0x00007ffda336cdca in ntdll!RtlQueryFeatureConfiguration () from /c/WINDOWS/SYSTEM32/ntdll.dll
#1 0x00007ffda3339169 in ntdll!RtlAcquireSRWLockExclusive () from /c/WINDOWS/SYSTEM32/ntdll.dll
#2 0x00007ff62e6f06f7 in shutdownCapability (cap=0x7ff62ee7b180, task=0x1895a375d50, safe=true) at rts/Capability.c:1157
#3 0x00007ff62e6f05ff in shutdownCapabilities (task=0x1895a375d50, safe=true) at rts/Capability.c:1250
#4 0x00007ff62e709014 in exitScheduler (wait_foreign=true) at rts/Schedule.c:2794
#5 0x00007ff62e6e58b8 in hs_exit_ (wait_foreign=true) at rts/RtsStartup.c:485
#6 0x00007ff62e6e5834 in hs_exit () at rts/RtsStartup.c:649
#7 0x00007ff62e6e1509 in main ()
(gdb)
```
My investigation thusfar suggests that the RTS is unable to shutdown due to an IO manager thread which is stuck in a foreign call. My suspicion is that this is due to the refactoring performed in !4745.9.8.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/23666HEAD regression: lookupIdSubst panic with GHCi2024-02-19T08:23:52ZRyan ScottHEAD regression: lookupIdSubst panic with GHCi_(Originally observed in a `head.hackage` issue: https://gitlab.haskell.org/ghc/head.hackage/-/issues/88#note_513332)_
GHC HEAD (at commit eb1a6ab1df473c7ec0e1cbb20fc7124706326ce1) panics when loading the following code into GHCi:
```h..._(Originally observed in a `head.hackage` issue: https://gitlab.haskell.org/ghc/head.hackage/-/issues/88#note_513332)_
GHC HEAD (at commit eb1a6ab1df473c7ec0e1cbb20fc7124706326ce1) panics when loading the following code into GHCi:
```hs
-- A.hs
{-# LANGUAGE CPP #-}
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE DefaultSignatures #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE UndecidableInstances #-}
module A where
import Data.Kind
type Sing :: k -> Type
#if __GLASGOW_HASKELL__ >= 909
type family Sing @k
#else
type family Sing
#endif
type SBool :: Bool -> Type
data SBool b where
SFalse :: SBool False
STrue :: SBool True
type instance Sing @Bool = SBool
type DefaultEq :: k -> k -> Bool
type family DefaultEq a b where
DefaultEq a a = 'True
DefaultEq a b = 'False
type Not :: Bool -> Bool
type family Not b where
Not False = True
Not True = False
sNot :: forall (b :: Bool). Sing b -> Sing (Not b)
sNot SFalse = STrue
sNot STrue = SFalse
class PEq a where
type (x :: a) == (y :: a) :: Bool
type (x :: a) /= (y :: a) :: Bool
type x /= y = Not (x == y)
class SEq a where
(%==) :: forall (x :: a) (y :: a).
Sing x -> Sing y -> Sing (x == y)
(%/=) :: forall (x :: a) (y :: a).
Sing x -> Sing y -> Sing (x /= y)
default (%/=) :: forall (x :: a) (y :: a).
((x /= y) ~ Not (x == y)) =>
Sing x -> Sing y -> Sing (x /= y)
(%/=) sx sy = sNot (sx %== sy)
```
```hs
-- B.hs
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE UndecidableInstances #-}
module B where
import GHC.Exts (TYPE)
import Type.Reflection
import A
type instance Sing @(TYPE rep) = TypeRep
instance PEq (TYPE rep) where
type x == y = DefaultEq x y
instance SEq (TYPE rep) where
tra %== trb =
case eqTypeRep tra trb of
Just HRefl -> STrue
Nothing -> undefined
```
```
$ ghc-9.9.20230716 --interactive B.hs
GHCi, version 9.9.20230716: https://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rscott/.ghci
[1 of 2] Compiling A ( A.hs, interpreted )
[2 of 2] Compiling B ( B.hs, interpreted )
<no location info>: error:
panic! (the 'impossible' happened)
GHC version 9.9.20230716:
lookupIdSubst
eta_i1Ia
InScope {rep_a1uz $c%==_a1uB $c%/=_a1GR x_a1GW y_a1GX a_i1HX
$dSEq_i1HY x_i1HZ y_i1I0 $d~_i1I1 eta_i1I2 eta1_i1I3 co_i1I4
$fSEqTYPE $fPEqTYPE}
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/GHC/Utils/Panic.hs:191:37 in ghc-9.9-inplace:GHC.Utils.Panic
pprPanic, called at compiler/GHC/Core/Subst.hs:197:17 in ghc-9.9-inplace:GHC.Core.Subst
CallStack (from HasCallStack):
panic, called at compiler/GHC/Utils/Error.hs:503:29 in ghc-9.9-inplace:GHC.Utils.Error
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
Failed, one module loaded.
```
GHC 9.6 and earlier do not panic, on the other hand. I was only able to trigger the panic with GHCi, and not with an ordinary invocation of GHC.9.10.1Torsten SchmitsTorsten Schmitshttps://gitlab.haskell.org/ghc/ghc/-/issues/23664HEAD regression: GHC no longer accepts fixity declaration in class2023-10-05T20:22:43ZRyan ScottHEAD regression: GHC no longer accepts fixity declaration in class_(Originally observed in a `head.hackage` issue: https://gitlab.haskell.org/ghc/head.hackage/-/issues/88)_
GHC HEAD (at commit eb1a6ab1df473c7ec0e1cbb20fc7124706326ce1) rejects the following program, which earlier versions of GHC accept..._(Originally observed in a `head.hackage` issue: https://gitlab.haskell.org/ghc/head.hackage/-/issues/88)_
GHC HEAD (at commit eb1a6ab1df473c7ec0e1cbb20fc7124706326ce1) rejects the following program, which earlier versions of GHC accept:
```hs
{-# LANGUAGE TypeFamilies #-}
module Bug where
class POrd a where
type a >= b
infix 4 >=
```
```
$ ghc-9.6.2 Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
$ ghc-9.9.20230716 Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:6:11: error: [GHC-54721]
‘>=’ is not a (visible) method of class ‘POrd’
|
6 | infix 4 >=
| ^^
```
Note that:
* It is important that `>=` also be the name of another identifier already in scope. If I rename `>=` to, say, `>==`, then the error disappears.
* It is also important that `>=` be an associated type family. If I change `>=` to an ordinary class method, then the error disappears.9.8.1sheafsam.derbyshire@gmail.comsheafsam.derbyshire@gmail.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/23561Apple clang 14.0.3 surfaces new default warnings; -Werror breaks Darwin builds2023-09-13T12:07:02ZBryan Rbryan@haskell.foundationApple clang 14.0.3 surfaces new default warnings; -Werror breaks Darwin builds
### Is this due to a new toolchain?
According to @angerman, there wasn't a OS/toolchain update that would have made this start happening.
*Update: The machines do have a newer version of clang than (some) other Darwin machines, so thi...
### Is this due to a new toolchain?
According to @angerman, there wasn't a OS/toolchain update that would have made this start happening.
*Update: The machines do have a newer version of clang than (some) other Darwin machines, so this is probably a factor.*
### Did something change recently in build configs that exposed these errors?
94f00e9b1d94635238571e9bc9cc415ef5253ccd added -optc-Werror to the +werror transformer, ~~but that happened back in December. I wouldn't expect to start seeing problems *now*.~~
*Update: This was only merged last week, so it is definitely related.*
### Why are they coming piecemeal?
5b6612bc4f6b0a7ecc9868750bee1c359ffca871 was written because "Darwin's toolchain inexplicably claims that `write_barrier` and friends have declarations without prototypes". But now there are more such functions. https://gitlab.haskell.org/ghc/ghc/-/jobs/1571118 complains of `initAdjustors`; https://gitlab.haskell.org/ghc/ghc/-/jobs/1571356 complains of `reportMemoryMap`; ~~https://gitlab.haskell.org/ghc/ghc/-/jobs/1571120 complains that FFI_GO_CLOSURES is undefined~~ (moved to #23568 since it's a different problem.) -Werror is complicit in all of these.
*Update: This is probably due to the nondeterminism of a multi-core build.*Bryan Rbryan@haskell.foundationBryan Rbryan@haskell.foundationhttps://gitlab.haskell.org/ghc/ghc/-/issues/23550HEAD regression: Core Lint error/panic due to out-of-scope dictionary2023-08-07T22:53:42ZRyan ScottHEAD regression: Core Lint error/panic due to out-of-scope dictionary_(Originally discovered in a `head.hackage` CI job [here](https://gitlab.haskell.org/ghc/head.hackage/-/jobs/1566976).)_
The `futhark-0.24.2` Hackage library will emit a Core Lint error if you build it with GHC HEAD. Here is a minimized..._(Originally discovered in a `head.hackage` CI job [here](https://gitlab.haskell.org/ghc/head.hackage/-/jobs/1566976).)_
The `futhark-0.24.2` Hackage library will emit a Core Lint error if you build it with GHC HEAD. Here is a minimized example:
```hs
{-# LANGUAGE Haskell2010 #-}
{-# LANGUAGE FlexibleContexts #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE UndecidableInstances #-}
{-# LANGUAGE NoMonoLocalBinds #-}
module Futhark.Optimise.Fusion.GraphRep (emptyGraph) where
import qualified Data.IntMap.Strict as IM
import qualified Data.Kind
import Data.Map.Strict (Map)
data NodeT = FreeNode VName
emptyGraph :: Stms SOACS -> [(Int, NodeT)]
emptyGraph stms = labelNodes inputnodes
where
labelNodes = zip [0 ..]
inputnodes = map FreeNode $ namesToList consumed
(_aliased, consumed) = analyseStms stms
data Aliases (rep :: Data.Kind.Type)
class RepTypes l where
type OpC l :: Data.Kind.Type -> Data.Kind.Type
instance RepTypes SOACS where
type OpC SOACS = SOAC
class Aliased rep where
instance AliasedOp (OpC rep (Aliases rep)) => Aliased (Aliases rep) where
class AliasedOp op where
instance Aliased rep => AliasedOp (SOAC rep) where
analyseStms ::
AliasedOp (OpC rep (Aliases rep)) =>
Stms rep ->
(Map VName Names, Names)
analyseStms = undefined
newtype Names = Names (IM.IntMap VName)
namesIntMap :: Names -> IM.IntMap VName
namesIntMap (Names m) = m
namesToList :: Names -> [VName]
namesToList = IM.elems . namesIntMap
data SOAC rep
data SOACS
data Stms rep
data VName
```
This will pass `-dcore-lint` with GHC 9.6 and earlier, but fail with GHC HEAD:
<details>
```
$ ~/Software/ghc-9.7.20230620/bin/ghc Bug.hs -dcore-lint -dno-typeable-binds
[1 of 1] Compiling Futhark.Optimise.Fusion.GraphRep ( Bug.hs, Bug.o )
*** Core Lint errors : in result of Desugar (before optimization) ***
Bug.hs:17:12: warning:
Out of scope: $dAliased_a1oc :: Aliased (Aliases SOACS)
[LclId]
In the RHS of emptyGraph :: Stms SOACS -> [(Int, NodeT)]
In the body of lambda with binder stms_a10c :: Stms SOACS
In an occurrence of $dAliased_a1oc :: Aliased (Aliases SOACS)
Substitution: <InScope = {}
IdSubst = []
TvSubst = []
CvSubst = []>
*** Offending Program ***
Rec {
namesIntMap :: Names -> IntMap VName
[LclId]
namesIntMap
= \ (ds_d1xW :: Names) ->
let {
m_a12O :: IntMap VName
[LclId]
m_a12O = ds_d1xW `cast` (N:Names[0] :: Names ~R# IntMap VName) } in
m_a12O
namesToList :: Names -> [VName]
[LclId]
namesToList
= . @(IntMap VName) @[VName] @Names (elems @VName) namesIntMap
analyseStms
:: forall rep.
AliasedOp (OpC rep (Aliases rep)) =>
Stms rep -> (Map VName Names, Names)
[LclId]
analyseStms
= \ (@rep_a1cf)
($dAliasedOp_a1cg
:: AliasedOp (OpC rep_a1cf (Aliases rep_a1cf))) ->
let {
$dIP_a1xk :: HasCallStack
[LclId]
$dIP_a1xk
= emptyCallStack
`cast` (Sym (N:IP[0] <"callStack">_N <CallStack>_N)
:: CallStack ~R# (?callStack::CallStack)) } in
let {
$dIP_a1nY :: HasCallStack
[LclId]
$dIP_a1nY
= (pushCallStack
(unpackCString# "undefined"#,
SrcLoc
(unpackCString# "main"#)
(unpackCString# "Futhark.Optimise.Fusion.GraphRep"#)
(unpackCString# "Bug.hs"#)
(I# 40#)
(I# 15#)
(I# 40#)
(I# 24#))
($dIP_a1xk
`cast` (N:IP[0] <"callStack">_N <CallStack>_N
:: (?callStack::CallStack) ~R# CallStack)))
`cast` (Sym (N:IP[0] <"callStack">_N <CallStack>_N)
:: CallStack ~R# (?callStack::CallStack)) } in
undefined
@LiftedRep @(Stms rep_a1cf -> (Map VName Names, Names)) $dIP_a1nY
emptyGraph :: Stms SOACS -> [(Int, NodeT)]
[LclIdX]
emptyGraph
= \ (stms_a10c :: Stms SOACS) ->
let {
$dAliasedOp_a1ob :: AliasedOp (SOAC (Aliases SOACS))
[LclId]
$dAliasedOp_a1ob
= $fAliasedOpSOAC @(Aliases SOACS) $dAliased_a1oc } in
let {
$dAliased_a1oc :: Aliased (Aliases SOACS)
[LclId]
$dAliased_a1oc = $fAliasedAliases @SOACS $dAliasedOp_a1od } in
let {
$dAliasedOp_a1od :: AliasedOp (OpC SOACS (Aliases SOACS))
[LclId]
$dAliasedOp_a1od
= $dAliasedOp_a1ob
`cast` (Sub (Sym (AliasedOp (D:R:OpCSOACS[0] <Aliases SOACS>_N))_N)
:: AliasedOp (SOAC (Aliases SOACS))
~R# AliasedOp (OpC SOACS (Aliases SOACS))) } in
let {
$dAliasedOp_a1o5 :: AliasedOp (OpC SOACS (Aliases SOACS))
[LclId]
$dAliasedOp_a1o5
= $dAliasedOp_a1ob
`cast` (Sub (Sym (AliasedOp (D:R:OpCSOACS[0] <Aliases SOACS>_N))_N)
:: AliasedOp (SOAC (Aliases SOACS))
~R# AliasedOp (OpC SOACS (Aliases SOACS))) } in
let {
ds_d1y2 :: (Map VName Names, Names)
[LclId]
ds_d1y2 = analyseStms @SOACS $dAliasedOp_a1o5 stms_a10c } in
let {
_aliased_a1o8 :: Map VName Names
[LclId]
_aliased_a1o8
= case ds_d1y2 of wild_00 { (_aliased_a1o8, consumed_a1o9) ->
_aliased_a1o8
} } in
let {
consumed_a1o9 :: Names
[LclId]
consumed_a1o9
= case ds_d1y2 of wild_00 { (_aliased_a1o8, consumed_a1o9) ->
consumed_a1o9
} } in
let {
_aliased_a10f :: Map VName Names
[LclId]
_aliased_a10f = _aliased_a1o8 } in
let {
consumed_a10g :: Names
[LclId]
consumed_a10g = consumed_a1o9 } in
let {
inputnodes_a10e :: [NodeT]
[LclId]
inputnodes_a10e
= letrec {
inputnodes_a1ov :: [NodeT]
[LclId]
inputnodes_a1ov
= $ @LiftedRep
@LiftedRep
@[VName]
@[NodeT]
(map @VName @NodeT (\ (ds_d1y1 :: VName) -> FreeNode ds_d1y1))
(namesToList consumed_a10g); } in
inputnodes_a1ov } in
let {
labelNodes_a10d :: forall {b}. [b] -> [(Int, b)]
[LclId]
labelNodes_a10d
= \ (@b_a1oC) ->
let {
$dEnum_a1wN :: Enum Int
[LclId]
$dEnum_a1wN = $fEnumInt } in
let {
$dNum_a1s2 :: Num Int
[LclId]
$dNum_a1s2 = $fNumInt } in
letrec {
labelNodes_a1wO :: [b_a1oC] -> [(Int, b_a1oC)]
[LclId]
labelNodes_a1wO
= zip @Int @b_a1oC (enumFrom @Int $dEnum_a1wN (I# 0#)); } in
labelNodes_a1wO } in
labelNodes_a10d @NodeT inputnodes_a10e
$fRepTypesSOACS [InlPrag=CONLIKE] :: RepTypes SOACS
[LclIdX[DFunId], Unf=DFun: \ -> C:RepTypes TYPE: SOACS]
$fRepTypesSOACS = C:RepTypes @SOACS
$fAliasedOpSOAC [InlPrag=CONLIKE]
:: forall rep. Aliased rep => AliasedOp (SOAC rep)
[LclIdX[DFunId],
Unf=DFun: \ (@rep_a109) (v_B1 :: Aliased rep_a109) ->
C:AliasedOp TYPE: SOAC rep_a109]
$fAliasedOpSOAC
= \ (@rep_a1xa) ($dAliased_a1xb :: Aliased rep_a1xa) ->
C:AliasedOp @(SOAC rep_a1xa)
$fAliasedAliases [InlPrag=CONLIKE]
:: forall rep.
AliasedOp (OpC rep (Aliases rep)) =>
Aliased (Aliases rep)
[LclIdX[DFunId],
Unf=DFun: \ (@rep_a10a)
(v_B1 :: AliasedOp (OpC rep_a10a (Aliases rep_a10a))) ->
C:Aliased TYPE: Aliases rep_a10a]
$fAliasedAliases
= \ (@rep_a1xf)
($dAliasedOp_a1xg
:: AliasedOp (OpC rep_a1xf (Aliases rep_a1xf))) ->
C:Aliased @(Aliases rep_a1xf)
end Rec }
*** End of Offense ***
<no location info>: error:
Compilation had errors
<no location info>: error: ExitFailure 1
```
</details>
If you omit `-dcore-lint`, then GHC will panic:
```
$ ~/Software/ghc-9.7.20230620/bin/ghc Bug.hs
[1 of 1] Compiling Futhark.Optimise.Fusion.GraphRep ( Bug.hs, Bug.o )
<no location info>: error:
panic! (the 'impossible' happened)
GHC version 9.7.20230620:
lookupIdSubst
$dAliased_a1oc
InScope {stms_a10c b_a1oC analyseStms namesToList $fAliasedAliases
$fAliasedOpSOAC $fRepTypesSOACS}
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/GHC/Utils/Panic.hs:191:37 in ghc-9.7-inplace:GHC.Utils.Panic
pprPanic, called at compiler/GHC/Core/Subst.hs:197:17 in ghc-9.7-inplace:GHC.Core.Subst
CallStack (from HasCallStack):
panic, called at compiler/GHC/Utils/Error.hs:503:29 in ghc-9.7-inplace:GHC.Utils.Error
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
```
I was able to trigger these bug using a GHC HEAD build at commit 1464a2a8de082f66ae250d63ab9d94dbe2ef8620.9.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/23541Array read operations are missing a read barrier2023-09-13T12:07:04ZBen GamariArray read operations are missing a read barrierIt turns out that pointer-array reads are currently missing the necessary acquire barrier to ensure soundness on platforms with weak memory ordering.It turns out that pointer-array reads are currently missing the necessary acquire barrier to ensure soundness on platforms with weak memory ordering.9.8.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/23493GHC 9.6 segfault at `updateThunk + 392`2023-09-19T14:20:26ZRebecca TurnerGHC 9.6 segfault at `updateThunk + 392`## Summary
I've found a very reliable segfault with `haskell-language-server` and GHC 9.6. I've [reported it to the `haskell-language-server` repository here](https://github.com/haskell/haskell-language-server/issues/3630) but I think i...## Summary
I've found a very reliable segfault with `haskell-language-server` and GHC 9.6. I've [reported it to the `haskell-language-server` repository here](https://github.com/haskell/haskell-language-server/issues/3630) but I think it may be a GHC bug, so I'm filing an issue here as well.
### Steps to reproduce
1. Open the editor and let `haskell-language-server` load our Haskell backend (~5700 modules). Unfortunately, our codebase is proprietary and can't be shared. I'll see if I can reproduce on an open-source codebase.
3. Make an edit and save the file. I typically add a definition like `foo :: (); foo = ()`.
4. `haskell-language-server` segfaults immediately.
### Expected behaviour
`haskell-language-server` should reindex and continue to provide language intelligence.
### Actual behaviour
`haskell-language-server` segfaults and exits unceremoniously.
### Debug information
There are two bits of good news with this bug. The first is that on macOS, a crash report is automatically written to `~/Library/Logs/DiagnosticReports`. The other is that it is very consistently reproducible. Here is the relevant excerpt from the crash report:
```
Crashed Thread: 32 ghc_worker
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000040
Exception Codes: 0x0000000000000001, 0x0000000000000040
Termination Reason: Namespace SIGNAL, Code 11 Segmentation fault: 11
Terminating Process: exc handler [61666]
VM Region Info: 0x40 is not in any region. Bytes before following region: 105553518919616
REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL
UNUSED SPACE AT START
--->
MALLOC_NANO (reserved) 600018000000-600020000000 [128.0M] rw-/rwx SM=NUL ...(unallocated)
...
Thread 32 Crashed:: ghc_worker
0 ??? 0x1046a3bd0 updateThunk + 392
1 ??? 0x10469caa8 schedule + 1188
2 ??? 0x10469caa8 schedule + 1188
3 libsystem_pthread.dylib 0x18a64ada0 thread_start + 8
```
It seems to always crash at `updateThunk + 392`.
## Environment
* GHC version used: 9.6.1
Optional:
* Operating System: macOS 13
* System Architecture: aarch64Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/23487debian 10 bindist depends on libzstd2023-07-20T16:09:44ZMatthew Pickeringdebian 10 bindist depends on libzstdSee https://gitlab.haskell.org/ghc/ghcup-ci/-/jobs/1545608
The debian 10 bindist should not depend on libzstd.See https://gitlab.haskell.org/ghc/ghcup-ci/-/jobs/1545608
The debian 10 bindist should not depend on libzstd.9.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/23400Segfault in GHC 9.2.7/9.4.5/9.6.1 with aligned pinned byte arrays2023-09-13T12:07:01ZdbeachamSegfault in GHC 9.2.7/9.4.5/9.6.1 with aligned pinned byte arrays## Summary
Use of aligned pinned byte arrays appears to be giving us a segmentation fault.
We don't see any issues if we use unpinned byte arrays or only use unaligned pinned byte arrays.
Compiling with GHC 9.2.7:
```
Thread 1 "segf...## Summary
Use of aligned pinned byte arrays appears to be giving us a segmentation fault.
We don't see any issues if we use unpinned byte arrays or only use unaligned pinned byte arrays.
Compiling with GHC 9.2.7:
```
Thread 1 "segfault" received signal SIGSEGV, Segmentation fault.
0x00000000017bd668 in LOOKS_LIKE_INFO_PTR_NOT_NULL (p=198) at includes/rts/storage/ClosureMacros.h:253
253 includes/rts/storage/ClosureMacros.h: No such file or directory.
(gdb) bt
#0 0x00000000017bd668 in LOOKS_LIKE_INFO_PTR_NOT_NULL (p=198) at includes/rts/storage/ClosureMacros.h:253
#1 0x00000000017bd6b7 in LOOKS_LIKE_INFO_PTR (p=198) at includes/rts/storage/ClosureMacros.h:258
#2 0x00000000017bd6f7 in LOOKS_LIKE_CLOSURE_PTR (p=0x42005d5000) at includes/rts/storage/ClosureMacros.h:264
#3 0x00000000017c00fc in scavenge_mutable_list1 (bd=0x4200401280, gen=0x1971910) at rts/sm/Scav.c:1606
#4 0x00000000017c0450 in scavenge_capability_mut_Lists1 (cap=0x195c240 <MainCapability>) at rts/sm/Scav.c:1715
#5 0x0000000001795cf9 in GarbageCollect (collect_gen=0, do_heap_census=false, is_overflow_gc=true, deadlock_detect=false, gc_type=2, cap=0x195c240 <MainCapability>, idle_cap=0x1985a20) at rts/sm/GC.c:505
#6 0x000000000176ab06 in scheduleDoGC (pcap=0x7fffffffd9e8, task=0x1983690, force_major=false, is_overflow_gc=true, deadlock_detect=false) at rts/Schedule.c:1860
#7 0x0000000001768b57 in schedule (initialCapability=0x195c240 <MainCapability>, task=0x1983690) at rts/Schedule.c:579
#8 0x000000000176b4df in scheduleWaitThread (tso=0x4200406ce8, ret=0x0, pcap=0x7fffffffdb10) at rts/Schedule.c:2630
#9 0x000000000176c924 in rts_evalLazyIO (cap=0x7fffffffdb10, p=0x1834d40, ret=0x0) at rts/RtsAPI.c:566
#10 0x0000000001783ee2 in hs_main (argc=1, argv=0x7fffffffdd38, main_closure=0x1834d40, rts_config=...) at rts/RtsMain.c:72
#11 0x0000000000406f01 in main ()
```
Compiling with GHC 9.4.5:
```
segfault: internal error: ASSERTION FAILED: file rts/sm/Storage.c, line 1605
(GHC version 9.4.5 for x86_64_unknown_linux)
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
Thread 1 "segfault" received signal SIGABRT, Aborted.
__pthread_kill_implementation (no_tid=0, signo=6, threadid=140737349969728) at ./nptl/pthread_kill.c:44
44 ./nptl/pthread_kill.c: No such file or directory.
(gdb) bt
#0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=140737349969728) at ./nptl/pthread_kill.c:44
#1 __pthread_kill_internal (signo=6, threadid=140737349969728) at ./nptl/pthread_kill.c:78
#2 __GI___pthread_kill (threadid=140737349969728, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
#3 0x00007ffff7c4b476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#4 0x00007ffff7c317f3 in __GI_abort () at ./stdlib/abort.c:79
#5 0x0000000002047ea6 in rtsFatalInternalErrorFn (s=0x2125e40 "ASSERTION FAILED: file %s, line %u\n", ap=0x7fffffffd4c8) at rts/RtsMessages.c:192
#6 0x0000000002047aae in barf (s=0x2125e40 "ASSERTION FAILED: file %s, line %u\n") at rts/RtsMessages.c:48
#7 0x0000000002047b11 in _assertFail (filename=0x212f55d "rts/sm/Storage.c", linenum=1605) at rts/RtsMessages.c:63
#8 0x000000000207feb2 in countOccupied (bd=0x4200402c00) at rts/sm/Storage.c:1605
#9 0x000000000206586f in GarbageCollect (config=..., cap=0x2447000 <MainCapability>, idle_cap=0x246dae0) at rts/sm/GC.c:778
#10 0x000000000204f97f in scheduleDoGC (pcap=0x7fffffffd9f0, task=0x246b750, force_major=false, is_overflow_gc=true, deadlock_detect=false, nonconcurrent=false) at rts/Schedule.c:1875
#11 0x000000000204dc13 in schedule (initialCapability=0x2447000 <MainCapability>, task=0x246b750) at rts/Schedule.c:583
#12 0x0000000002050b0e in scheduleWaitThread (tso=0x4200406ce8, ret=0x0, pcap=0x7fffffffdb10) at rts/Schedule.c:2647
#13 0x00000000020435b8 in rts_evalLazyIO (cap=0x7fffffffdb10, p=0x2154ec8, ret=0x0) at rts/RtsAPI.c:566
#14 0x000000000204796e in hs_main (argc=1, argv=0x7fffffffdd38, main_closure=0x2154ec8, rts_config=...) at rts/RtsMain.c:72
#15 0x0000000000406eab in main ()
```
Compiling with GHC 9.6.1:
```
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff7290640 (LWP 1316306)]
Thread 1 "segfault" received signal SIGSEGV, Segmentation fault.
LOOKS_LIKE_CLOSURE_PTR (p=0xc0) at rts/include/rts/storage/ClosureMacros.h:289
289 rts/include/rts/storage/ClosureMacros.h: No such file or directory.
(gdb) bt
#0 LOOKS_LIKE_CLOSURE_PTR (p=0xc0) at rts/include/rts/storage/ClosureMacros.h:289
#1 0x00000000016e986e in scavenge_mutable_list (bd=0x4200402440, gen=0x19f48e8) at rts/sm/Scav.c:1636
#2 0x00000000016e9b9c in scavenge_capability_mut_lists (cap=0x19f2500 <MainCapability>) at rts/sm/Scav.c:1745
#3 0x00000000016d66bd in GarbageCollect (collect_gen=0, do_heap_census=false, is_overflow_gc=true, deadlock_detect=false, gc_type=0, cap=0x19f2500 <MainCapability>, idle_cap=0x0) at rts/sm/GC.c:512
#4 0x00000000016c4e09 in scheduleDoGC (pcap=0x7fffffffda08, task=0x1a023c0, force_major=false, is_overflow_gc=true, deadlock_detect=false) at rts/Schedule.c:1883
#5 0x00000000016c42ae in schedule (initialCapability=0x19f2500 <MainCapability>, task=0x1a023c0) at rts/Schedule.c:575
#6 0x00000000016c5831 in scheduleWaitThread (tso=0x4200405380, ret=0x0, pcap=0x7fffffffdb10) at rts/Schedule.c:2651
#7 0x000000000171248c in rts_evalLazyIO (cap=0x7fffffffdb10, p=0x18abec8, ret=0x0) at rts/RtsAPI.c:562
#8 0x00000000016be90d in hs_main (argc=1, argv=0x7fffffffdd38, main_closure=0x18abec8, rts_config=...) at rts/RtsMain.c:72
#9 0x00000000004078e3 in main ()
```
## Steps to reproduce
Don't have a shareable example yet.
Can someone suggest some ways to try and get a minimal reproducable example? The code at the momemnt is large and complex with multiple reads/writes/copies/moves but there doesn't seem to be a consistent point of failure.
## Expected behavior
n/a
## Environment
* GHC version used: GHC-9.2.7 / GHC 9.4.5 / GHC 9.6.1
Optional:
* Operating System: Ubuntu
* System Architecture: x86-64Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/23378Windows: runtime linker regression (isatty) with GHC 9.4.5+2023-10-12T10:48:42ZRyan ScottWindows: runtime linker regression (isatty) with GHC 9.4.5+_(Originally spun off from https://gitlab.haskell.org/ghc/ghc/-/issues/23309#note_497937 )_
Given the following two files, distilled from the `text-ansi` library:
```hs
-- A.hs
module A where
import Foreign.C.Types
import System.IO.Un..._(Originally spun off from https://gitlab.haskell.org/ghc/ghc/-/issues/23309#note_497937 )_
Given the following two files, distilled from the `text-ansi` library:
```hs
-- A.hs
module A where
import Foreign.C.Types
import System.IO.Unsafe
isatty :: Bool
isatty =
unsafePerformIO (c_isatty 1) == 1
{-# NOINLINE isatty #-}
foreign import ccall unsafe "isatty"
c_isatty :: CInt -> IO CInt
```
```hs
-- B.hs
{-# LANGUAGE TemplateHaskell #-}
module B where
import Foreign.C.String
import Language.Haskell.TH
import A
$(do runIO $ print isatty
return [])
```
If you compile this with GHC 9.4.4 or earlier, it will run as expected:
```
$ ghc-9.2.7 -fforce-recomp B.hs
[1 of 2] Compiling A ( A.hs, A.o )
[2 of 2] Compiling B ( B.hs, B.o )
False
```
If you compile this with GHC 9.4.5 or later, however, the runtime linker will crash on the `isatty` symbol:
```
$ ghc-9.4.5 -fforce-recomp B.hs
[1 of 2] Compiling A ( A.hs, A.o )
[2 of 2] Compiling B ( B.hs, B.o )
ghc-9.4.5.exe: | C:\Users\winferno\Documents\Hacking\Haskell\A.o: unknown symbol `isatty'
ghc-9.4.5.exe: Could not load Object Code C:\Users\winferno\Documents\Hacking\Haskell\A.o.
<no location info>: error:
```
(Also, the error message appears _before_ the "`error:`" part, which is odd. That isn't the main point of this issue, however.)
This is almost certainly an unintended side effect of !9475. A similar issue was diagnosed in #23309, but unlike that issue, the issue here is not caused by a missing `mingwex` dependency. If you compile the program with `-lmingwex`, the same runtime linker crash still occurs. The patch in !10360 does not fix the issue here either.9.4.6Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/23222Segfaults in atomic-counter (regression in 9.6)2024-01-30T16:15:13ZRodrigo MesquitaSegfaults in atomic-counter (regression in 9.6)I've come across what I think are more than one distinct bugs in running `atomic-counter`'s benchmarks. If we are able to discern them later ahead we can create a separate ticket.
The easiest to reproduce is an immediate segfault on sta...I've come across what I think are more than one distinct bugs in running `atomic-counter`'s benchmarks. If we are able to discern them later ahead we can create a separate ticket.
The easiest to reproduce is an immediate segfault on start with 9.6.1 and HEAD which doesn't occur with other versions.
Simply clone `atom-counter` and run `cabal run bench -- -j1` with `9.1`.
Note that any value passed with `-j` will cause the segfault. Omitting the `-j` flag will make the program no longer segfault.
The other is bug seems to be related to concurrency/atomic operations. I was able to somewhat reliably reproduce by running `cabal bench` with `9.6`, and could reproduce another crash with `9.4` but less reliably.
```
$ cabal bench
All
Correctness: OK (3.49s)
+++ OK, passed 10000 tests.
Read/write contention with 10 iterations and 1 threads
Counter: OK (0.45s)
18.1 μs ± 1.6 μs
IORef inconsistent: OK (1.83s)
18.1 μs ± 1.7 μs, 1.00x
IORef atomic: OK (1.05s)
20.1 μs ± 1.6 μs, 1.11x
MVar: OK (1.00s)
18.9 μs ± 1.3 μs, 1.04x
TMVar: OK (0.57s)
22.7 μs ± 1.6 μs, 1.25x
TVar: OK (1.17s)
22.6 μs ± 1.8 μs, 1.25x
Addr: OK (0.47s)
17.3 μs ± 1.7 μs, 0.96x
Read/write contention with 100 iterations and 1 threads
Counter: OK (0.66s)
26.4 μs ± 1.7 μs
IORef inconsistent: OK (0.39s)
29.2 μs ± 2.4 μs, 1.11x
IORef atomic: OK (1.76s)
39.1 μs ± 2.6 μs, 1.48x
MVar: OK (0.43s)
32.6 μs ± 3.2 μs, 1.24x
TMVar: bench: internal error: TSO object (0x16d65ee40) entered!
(GHC version 9.6.1 for aarch64_apple_darwin)
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
Benchmark bench: ERROR
Error: cabal: Benchmarks failed for bench:bench from atomic-counter-0.1.
```
Architecture: aarch64 (Apple Silicon)Ben GamariRodrigo MesquitaBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/23146segfault in the presence of `UnliftedDataTypes`2023-09-13T12:07:00ZMagnus Viernickelsegfault in the presence of `UnliftedDataTypes`## Summary
When trying to add compatibility for unlifted datatypes for `generics-sop`, I encounter a segfault trying to run my code.
## Steps to reproduce
I don't have a small reproducer yet because I haven't really found the reason ...## Summary
When trying to add compatibility for unlifted datatypes for `generics-sop`, I encounter a segfault trying to run my code.
## Steps to reproduce
I don't have a small reproducer yet because I haven't really found the reason for the issue but generally, We have a generic class
```haskell
class (All SListI (Code a)) => Generic (a :: TYPE ('BoxedRep levity)) where
-- | The code of a datatype.
--
-- This is a list of lists of its components. The outer list contains
-- one element per constructor. The inner list contains one element
-- per constructor argument (field).
--
-- /Example:/ The datatype
--
-- > data Tree = Leaf Int | Node Tree Tree
--
-- is supposed to have the following code:
--
-- > type instance Code (Tree a) =
-- > '[ '[ Int ]
-- > , '[ Tree, Tree ]
-- > ]
--
type Code a :: [[TYPE ('BoxedRep levity)]]
type Code (a :: TYPE ('BoxedRep levity)) = GCode a
-- | Converts from a value to its structural representation.
from :: a -> Rep a
default from :: (levity ~ 'Lifted, GFrom a, DeferMkLifted GHC.Generic a, Rep a ~ SOP I (GCode a))
=> a -> Rep a
from = gfrom
-- | Converts from a structural representation back to the
-- original value.
to :: Rep a -> a
default to :: (levity ~ 'Lifted, GTo a, DeferMkLifted GHC.Generic a, Rep a ~ SOP I (GCode a))
=> Rep a -> a
to = gto
```
, then we have `data family`s for each of the representations; e.g. n-ary products are represented as:
```haskell
data family NP :: forall levity k. (k -> TYPE ('BoxedRep levity)) -> [k] -> TYPE ('BoxedRep levity)
data instance NP @'Lifted f xs where
Nil :: NP f '[]
(:*) :: f x -> NP f xs -> NP f (x ': xs)
data instance NP @'Unlifted f xs where
UNil :: NP f '[]
(::*) :: f x -> NP f xs -> NP f (x ': xs)
```
This is such that the representation that we convert from is also `unlifted`, it's probably not needed with something like
```haskell
data family I :: forall levin levout. TYPE ('Boxedrep levin) -> TYPE ('BoxedRep levout)
data instance I @'Unlifted @'Lifted a = ULI a
```
but it's there for completeness.
Now I generate an instance as such:
```haskell
type UT :: UnliftedType
data UT = UL | UN UT UT
instance Generic UT where
type Code UT = '[ '[], '[UT , UT]]
from UL = USOP (UZ UNil)
from (UN l r) = USOP (US (UZ (UI l ::* UI r ::* UNil)))
-- .. to omitted but it's basically the opposite way around
```
now something like `let bla = from (UN UL UL) in undefined bla` segfaults.
I also have a more elaborate example that segfaults:
```haskell
type UEq :: UnliftedType -> Constraint
class UEq a where
ueq :: a -> a -> Bool
default ueq :: (Generic a, All2 UEq (Code a)) => a -> a -> Bool
ueq = gueq
infix 4 `ueq`
gueq :: forall (a :: UnliftedType). (Generic a, All2 UEq (Code a)) => a -> a -> Bool
gueq (from -> USOP x) (from -> USOP y) = constrsSame x y
where
constrsSame :: forall (xss :: [[UnliftedType]]). (All2 UEq xss) => NS (NP I) xss -> NS (NP I) xss -> Bool
constrsSame (US x') (US y') = constrsSame x' y'
constrsSame (UZ x') (UZ y') = fieldsSame x' y'
constrsSame _ _ = False
fieldsSame :: forall (xs :: [UnliftedType]). All UEq xs => NP I xs -> NP I xs -> Bool
fieldsSame (UI x' ::* xs) (UI y' ::* ys) = x' `ueq` y' && fieldsSame xs ys
fieldsSame UNil UNil = True
instance UEq UT
main :: IO ()
main = print $ UN (UN UL UL) (UN UL UL) `ueq` UN (UN UL UL) (UN UL UL)
```
You can try it out at https://github.com/MangoIV/generics-sop/tree/mangoiv/unlifted
## Expected behavior
running
```haskell
print $ UN (UN UL UL) (UN UL UL) `ueq` UN (UN UL UL) (UN UL UL)
```
prints `"True"`.
## Environment
* GHC version used:
- ghc927, ghc944, ghc961
Optional:
* Operating System: NixOS 22.11
* System Architecture: x86_64-linuxRodrigo MesquitaRodrigo Mesquitahttps://gitlab.haskell.org/ghc/ghc/-/issues/23102Simplifier: `countValArgs` counts type args2023-05-15T22:34:30ZSebastian GrafSimplifier: `countValArgs` counts type argsAs I got aware of in https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10088#note_486696, this is the current definition (at least since Sep 22) of `GHC.Core.Opt.Simplify.Utils.countValARgs`:
```hs
countValArgs :: SimplCont -> Int
-- ...As I got aware of in https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10088#note_486696, this is the current definition (at least since Sep 22) of `GHC.Core.Opt.Simplify.Utils.countValARgs`:
```hs
countValArgs :: SimplCont -> Int
-- Count value arguments only
countValArgs (ApplyToTy { sc_cont = cont }) = 1 + countValArgs cont --- UH OH
countValArgs (ApplyToVal { sc_cont = cont }) = 1 + countValArgs cont
countValArgs (CastIt _ cont) = countValArgs cont
countValArgs _ = 0
```
The first clause should not increment the count. Fortunately it is only used in `mkArgInfo`, but it could still have detrimental effect.
This means we potentially mis-optimise a few programs. The fix is simple and should be easy to backport.