GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2021-04-12T18:04:26Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/17439Segfault during GC with -ffull-laziness and unsafeCoerce#2021-04-12T18:04:26ZLeon P Smithleon.p.smith@gmail.comSegfault during GC with -ffull-laziness and unsafeCoerce### Summary
The sample program segfaults during the call to `performGC`
## Steps to reproduce
Compile [Main.hs](/uploads/ed1ba0432684bd05da3b0e2986e93bcc/Main.hs), and run it. Unfortunately there are some sensitivities when using `per...## Summary
The sample program segfaults during the call to `performGC`
## Steps to reproduce
Compile [Main.hs](/uploads/ed1ba0432684bd05da3b0e2986e93bcc/Main.hs), and run it. Unfortunately there are some sensitivities when using `performMinorGC` that aren't fully understood yet; but an updated version of [Main.hs](https://gitlab.haskell.org/ghc/ghc/uploads/14b0bf94e89e72a5240ba2fe571f12c1/Main.hs) uses `performMajorGC` instead and removes the calls to `getEnvironment`.
## Environment
* GHC version used: 8.4.3
* Operating System: NixOS
* System Architecture: x648.8.2https://gitlab.haskell.org/ghc/ghc/-/issues/17353ghc 8.8.1 fails on macOS 10.15 Catalina2020-02-24T22:03:07Zfxcoudertghc 8.8.1 fails on macOS 10.15 Catalina## Summary
ghc 8.8.1 compiled on macOS 10.15 with system compiler (Xcode 11.1) completes bootstrap, but the compiler later fails to run simple programs with a memory-related error:
```
ghc: mmap 131072 bytes at 0x0: Operation not permi...## Summary
ghc 8.8.1 compiled on macOS 10.15 with system compiler (Xcode 11.1) completes bootstrap, but the compiler later fails to run simple programs with a memory-related error:
```
ghc: mmap 131072 bytes at 0x0: Operation not permitted
ghc: Try specifying an address with +RTS -xm<addr> -RTS
ghc: internal error: m32_allocator_init: Failed to map
(GHC version 8.8.1 for x86_64_apple_darwin)
```
This is reproducible in several setups, both inside VMs and on physical hardware.
## Steps to reproduce
On macOS 10.15 Catalina, with Xcode 11.1 (system compiler):
- ghc 8.8.1 is built from ghc-8.8.1-src.tar.xz (as part of Homebrew)
- bootstrap completes
- Run a simple test, watch if fail:
```
rmeur /tmp $ cat hello.rs
main = putStrLn "Hello Homebrew"
rmeur /tmp $ /usr/local/Cellar/ghc/8.8.1/bin/runghc -v hello.rs
Glasgow Haskell Compiler, Version 8.8.1, stage 2 booted by GHC version 8.6.5
Using binary package database: /usr/local/Cellar/ghc/8.8.1/lib/ghc-8.8.1/package.conf.d/package.cache
package flags []
loading package database /usr/local/Cellar/ghc/8.8.1/lib/ghc-8.8.1/package.conf.d
wired-in package ghc-prim mapped to ghc-prim-0.5.3
wired-in package integer-wired-in mapped to integer-gmp-1.0.2.0
wired-in package base mapped to base-4.13.0.0
wired-in package rts mapped to rts
wired-in package template-haskell mapped to template-haskell-2.15.0.0
wired-in package ghc mapped to ghc-8.8.1
package flags []
loading package database /usr/local/Cellar/ghc/8.8.1/lib/ghc-8.8.1/package.conf.d
wired-in package ghc-prim mapped to ghc-prim-0.5.3
wired-in package integer-wired-in mapped to integer-gmp-1.0.2.0
wired-in package base mapped to base-4.13.0.0
wired-in package rts mapped to rts-1.0
wired-in package template-haskell mapped to template-haskell-2.15.0.0
wired-in package ghc mapped to ghc-8.8.1
*** Desugar:
*** Simplify [expr]:
!!! Simplify [expr]: finished in 0.18 milliseconds, allocated 0.056 megabytes
*** CorePrep [expr]:
!!! CorePrep [expr]: finished in 3.17 milliseconds, allocated 1.705 megabytes
*** ByteCodeGen [Ghci1]:
!!! ByteCodeGen [Ghci1]: finished in 0.10 milliseconds, allocated 0.029 megabytes
ghc: mmap 131072 bytes at 0x0: Operation not permitted
ghc: Try specifying an address with +RTS -xm<addr> -RTS
ghc: internal error: m32_allocator_init: Failed to map
(GHC version 8.8.1 for x86_64_apple_darwin)
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
```
## Expected behavior
The program should run without error.
## Environment
* GHC version used:
Optional:
* Operating System: macOS 10.15 Catalina
* System Architecture: x86_648.8.2https://gitlab.haskell.org/ghc/ghc/-/issues/15742GHC configure step can fail when CC=clang2020-01-07T18:46:10ZjudahGHC configure step can fail when CC=clangIn our internal build of GHC from source, we are building it on Linux with Clang. Unfortunately, this results in an error on ghc-8.4.3:
```
$ ./configure CC=clang CC_STAGE0=clang --prefix=... --with-ghc=...
...
checking version of gcc.....In our internal build of GHC from source, we are building it on Linux with Clang. Unfortunately, this results in an error on ghc-8.4.3:
```
$ ./configure CC=clang CC_STAGE0=clang --prefix=... --with-ghc=...
...
checking version of gcc... configure: error: Need at least gcc version 4.4 (4.7+ recommended)
```
Looking in the code, it seems that the logic is wrong: it calls `$CC -v` and parses the output unconditionally, whether or not the compiler is actually GCC:
https://github.com/ghc/ghc/blob/ce7a1c4ae4c93f2d0d3d7a0b573ddd876fc855c2/aclocal.m4\#L1245
In our case, the test fails since the compiler is a build of Clang that doesn't produce a useful version number.
I also realized that on macOS (where gcc \*is\* clang), this test succeeds accidentally, since the output of `gcc -v` is:
```
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 10.0.0 (clang-1000.10.44.2)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
judahjacobson-macbookpro:~ judahjacobson$ gcc -v
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 10.0.0 (clang-1000.10.44.2)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC configure step can fail when CC=clang","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In our internal build of GHC from source, we are building it on Linux with Clang. Unfortunately, this results in an error on ghc-8.4.3:\r\n{{{\r\n$ ./configure CC=clang CC_STAGE0=clang --prefix=... --with-ghc=...\r\n...\r\nchecking version of gcc... configure: error: Need at least gcc version 4.4 (4.7+ recommended)\r\n}}}\r\nLooking in the code, it seems that the logic is wrong: it calls `$CC -v` and parses the output unconditionally, whether or not the compiler is actually GCC:\r\nhttps://github.com/ghc/ghc/blob/ce7a1c4ae4c93f2d0d3d7a0b573ddd876fc855c2/aclocal.m4#L1245\r\nIn our case, the test fails since the compiler is a build of Clang that doesn't produce a useful version number.\r\n\r\nI also realized that on macOS (where gcc *is* clang), this test succeeds accidentally, since the output of {{{gcc -v}}} is:\r\n{{{\r\nConfigured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/usr/include/c++/4.2.1\r\nApple LLVM version 10.0.0 (clang-1000.10.44.2)\r\nTarget: x86_64-apple-darwin17.7.0\r\nThread model: posix\r\nInstalledDir: /Library/Developer/CommandLineTools/usr/bin\r\njudahjacobson-macbookpro:~ judahjacobson$ gcc -v\r\nConfigured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/usr/include/c++/4.2.1\r\nApple LLVM version 10.0.0 (clang-1000.10.44.2)\r\nTarget: x86_64-apple-darwin17.7.0\r\nThread model: posix\r\nInstalledDir: /Library/Developer/CommandLineTools/usr/bin\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.8.2https://gitlab.haskell.org/ghc/ghc/-/issues/17266Invalid PATH set for `-B` dirs when calling gcc to link2020-01-07T04:30:48ZandrewjcgInvalid PATH set for `-B` dirs when calling gcc to link## Summary
When `-B` values are set in `-optl`, GHC constructs a seemingly invalid `PATH` from it, using `;` instead of `:` to prepend to the existing `PATH`.
## Steps to reproduce
On a system where all executables needed to run GHC a...## Summary
When `-B` values are set in `-optl`, GHC constructs a seemingly invalid `PATH` from it, using `;` instead of `:` to prepend to the existing `PATH`.
## Steps to reproduce
On a system where all executables needed to run GHC are in `/bin`:
```
$ cat Main.hs
module Main where
main = return ()
$ PATH=/bin ghc -optl-B/var/tmp Main
[1 of 1] Compiling Main ( Main.hs, Main.o )
Linking Main ...
collect2: fatal error: cannot find 'ld'
compilation terminated.
```
(`strace` shows `PATH="/var/tmp";/bin` being set in the environment).
## Expected behavior
Link sample program successfully.
## Environment
* GHC version used: 7.6.3 and 8.4.4
Optional:
* Operating System: linux
* System Architecture: x86_648.8.2https://gitlab.haskell.org/ghc/ghc/-/issues/17437Segfault with -fenable-rewrite-rules2019-11-12T11:38:13ZSylvain HenrySegfault with -fenable-rewrite-rules## Summary
A very simple program compiled by GHC segfaults if `-fenable-rewrite-rules` command-line option is passed.
I think it is similar to #15570 so you might want to read it too.
## Steps to reproduce
In the context of the reimp...## Summary
A very simple program compiled by GHC segfaults if `-fenable-rewrite-rules` command-line option is passed.
I think it is similar to #15570 so you might want to read it too.
## Steps to reproduce
In the context of the reimplementation of the integer libraries into a single `ghc-bignum` library, I'm trying to compile this simple example (with a modified GHC):
```
main :: IO ()
main = print (-1 :: Integer)
```
```
> ghc-stage1 -Wall -fforce-recomp Test.hs -fno-ignore-interface-pragmas && ./Test
[1 of 1] Compiling Main ( Test.hs, Test.o )
Linking Test ...
-1
> ghc-stage1 -Wall -fforce-recomp Test.hs -fno-ignore-interface-pragmas -fenable-rewrite-rules && ./Test
[1 of 1] Compiling Main ( Test.hs, Test.o )
Linking Test ...
[1] 757796 segmentation fault (core dumped) ./Test
```
GDB backtrace:
```
Program received signal SIGSEGV, Segmentation fault.
0x0000000000409b84 in frame_dummy ()
(gdb) bt
#0 0x0000000000409b84 in frame_dummy ()
#1 0x0000000000000000 in ?? ()
```
### Core
Core doesn't look suspicious:
* `-XNegativeLiterals` isn't enabled hence `Num's negate` is applied to the literal `1`.
* `negate` for `Integer` (`integerNegate`) is inlined as it is not marked `NOINLINE` in `ghc-bignum` (yet).
* the only difference is that the precedence (`ww1`) is inlined (`0#`) with `-fenable-rewrite-rules`
```haskell
-- GOOD
main1 :: String
[GblId]
main1
= case GHC.Show.$fShow(,)1 of { GHC.Types.I# ww1 ->
case 1 of {
GHC.Num.Integer.IS ds1 ->
case ds1 of ds2 {
__DEFAULT ->
GHC.Show.$w$cshowsPrec4
ww1
(GHC.Num.Integer.IS (GHC.Prim.negateInt# ds2))
(GHC.Types.[] @ Char);
-9223372036854775808# ->
GHC.Show.$w$cshowsPrec4
ww1 GHC.Num.Integer.integerAbs1 (GHC.Types.[] @ Char)
};
GHC.Num.Integer.IP dt ->
case GHC.Prim.uncheckedIShiftRL# (GHC.Prim.sizeofByteArray# dt) 3#
of {
__DEFAULT ->
GHC.Show.$w$cshowsPrec4
ww1 (GHC.Num.Integer.IN dt) (GHC.Types.[] @ Char);
1# ->
case GHC.Prim.indexWordArray# dt 0# of {
__DEFAULT ->
GHC.Show.$w$cshowsPrec4
ww1 (GHC.Num.Integer.IN dt) (GHC.Types.[] @ Char);
9223372036854775808## ->
GHC.Show.$w$cshowsPrec4
ww1 GHC.Num.Integer.integerNegate1 (GHC.Types.[] @ Char)
}
};
GHC.Num.Integer.IN dt ->
GHC.Show.$w$cshowsPrec4
ww1 (GHC.Num.Integer.IP dt) (GHC.Types.[] @ Char)
}
}
```
```haskell
-- BAD
main1
= case 1 of {
GHC.Num.Integer.IS ds1 ->
case ds1 of ds2 {
__DEFAULT ->
GHC.Show.$w$cshowsPrec4
0#
(GHC.Num.Integer.IS (GHC.Prim.negateInt# ds2))
(GHC.Types.[] @ Char);
-9223372036854775808# ->
GHC.Show.$w$cshowsPrec4
0# GHC.Num.Integer.integerAbs1 (GHC.Types.[] @ Char)
};
GHC.Num.Integer.IP dt ->
case GHC.Prim.uncheckedIShiftRL# (GHC.Prim.sizeofByteArray# dt) 3#
of {
__DEFAULT ->
GHC.Show.$w$cshowsPrec4
0# (GHC.Num.Integer.IN dt) (GHC.Types.[] @ Char);
1# ->
case GHC.Prim.indexWordArray# dt 0# of {
__DEFAULT ->
GHC.Show.$w$cshowsPrec4
0# (GHC.Num.Integer.IN dt) (GHC.Types.[] @ Char);
9223372036854775808## ->
GHC.Show.$w$cshowsPrec4
0# GHC.Num.Integer.integerNegate1 (GHC.Types.[] @ Char)
}
};
GHC.Num.Integer.IN dt ->
GHC.Show.$w$cshowsPrec4
0# (GHC.Num.Integer.IP dt) (GHC.Types.[] @ Char)
}
```
### STG
STG looks normal too:
* Integer literal `1` has been replaced with a constructor application `IS 1#` (equivalent to `S# 1#` in `integer-gmp`).
* the only difference is still that the precedence (`ww1`) is inlined (`0#`) with `-fenable-rewrite-rules`
```haskell
-- BAD
main1 :: GHC.Base.String
[GblId] =
\u []
case GHC.Num.Integer.IS [1#] of {
GHC.Num.Integer.IS ds1 [Occ=Once!] ->
case ds1 of ds2 [Occ=Once] {
__DEFAULT ->
case negateInt# [ds2] of sat [Occ=Once] {
__DEFAULT ->
let {
sat [Occ=Once] :: GHC.Num.Integer.Integer
[LclId] =
CCCS GHC.Num.Integer.IS! [sat];
} in GHC.Show.$w$cshowsPrec4 0# sat GHC.Types.[];
};
-9223372036854775808# ->
GHC.Show.$w$cshowsPrec4
0# GHC.Num.Integer.integerAbs1 GHC.Types.[];
};
GHC.Num.Integer.IP dt ->
case sizeofByteArray# [dt] of sat [Occ=Once] {
__DEFAULT ->
case uncheckedIShiftRL# [sat 3#] of {
__DEFAULT ->
let {
sat [Occ=Once] :: GHC.Num.Integer.Integer
[LclId] =
CCCS GHC.Num.Integer.IN! [dt];
} in GHC.Show.$w$cshowsPrec4 0# sat GHC.Types.[];
1# ->
case indexWordArray# [dt 0#] of {
__DEFAULT ->
let {
sat [Occ=Once] :: GHC.Num.Integer.Integer
[LclId] =
CCCS GHC.Num.Integer.IN! [dt];
} in GHC.Show.$w$cshowsPrec4 0# sat GHC.Types.[];
9223372036854775808## ->
GHC.Show.$w$cshowsPrec4
0# GHC.Num.Integer.integerNegate1 GHC.Types.[];
};
};
};
GHC.Num.Integer.IN dt [Occ=Once] ->
let {
sat [Occ=Once] :: GHC.Num.Integer.Integer
[LclId] =
CCCS GHC.Num.Integer.IP! [dt];
} in GHC.Show.$w$cshowsPrec4 0# sat GHC.Types.[];
};
```
### Rules
Both report 2 firing rules:
```
Rule fired: Class op show (BUILTIN)
Rule fired: Class op negate (BUILTIN)
```
```
Rule fired
Rule: Class op show
Module: (BUILTIN)
Before: GHC.Show.show
TyArg GHC.Num.Integer.Integer ValArg GHC.Show.$fShowInteger
After: GHC.Show.$fShowInteger_$cshow
Cont: ApplyToVal nodup x
Stop[BoringCtxt] GHC.Base.String
Rule fired
Rule: Class op negate
Module: (BUILTIN)
Before: GHC.Num.negate
TyArg GHC.Num.Integer.Integer ValArg GHC.Num.$fNumInteger
After: GHC.Num.Integer.integerNegate
Cont: ApplyToVal nodup 1
StrictArg GHC.Show.$w$cshowsPrec4
ApplyToVal nodup w2
Stop[BoringCtxt] GHC.Base.String
```
### Inlinings
Both report the same inlinings:
```
Inlining done: System.IO.print
Inlining done: GHC.Show.$fShowInteger_$cshow
Inlining done: GHC.Show.$fShowInteger_$cshowsPrec
Inlining done: GHC.Num.Integer.integerNegate
Inlining done: GHC.TopHandler.runMainIO
```
Does anyone know what to do to debug this from here? Does `-fenable-rewrite-rules` have effects later in the pipeline (Cmm, etc.)?
The environment to reproduce this is a bit tricky as I would need to upload modified boot-libs too, but I could provide it if needed. In the meantime, I can provide any log and try any suggestion.
## Environment
* GHC version used: modified GHC head that can be found here: https://gitlab.haskell.org/hsyl20/ghc/tree/hsyl20-integer
* Operating System: Linux 5.3.8
* System Architecture: x86-648.8.2Sylvain HenrySylvain Henryhttps://gitlab.haskell.org/ghc/ghc/-/issues/17448Core Lint building statistics-0.15.1.1 with GHC 8.82019-11-07T17:19:19ZBen GamariCore Lint building statistics-0.15.1.1 with GHC 8.8Seen in [this](https://gitlab.haskell.org/ghc/head.hackage/-/jobs/194178) head.hackage build:
```
*** Core Lint errors : in result of Simplifier ***
<no location info>: warning:
[in body of letrec with binders ipv1_saFXs :: MVector
...Seen in [this](https://gitlab.haskell.org/ghc/head.hackage/-/jobs/194178) head.hackage build:
```
*** Core Lint errors : in result of Simplifier ***
<no location info>: warning:
[in body of letrec with binders ipv1_saFXs :: MVector
(PrimState (ST s_a3NiN)) Double]
Occurrence is GlobalId, but binding is LocalId
sIZEOF_DOUBLE [InlPrag=NOUSERINLINE[2]] :: Int
[GblId,
Str=m,
Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True,
WorkFree=True, Expandable=True,
Guidance=ALWAYS_IF(arity=0,unsat_ok=True,boring_ok=True)}]
```
The problem appears to be:
```haskell
case sIZEOF_DOUBLE of wild3_amtK [Occ=Once]
{ I# y_amtO [Occ=Once] ->
let {
sIZEOF_DOUBLE_rfHl :: Int
[LclId]
sIZEOF_DOUBLE_rfHl = wild3_amtK } in
case newByteArray#
@ (PrimState (ST s_a3NiN))
(*# x_amtM y_amtO)
(s1_a5r6
`cast` ((State#
(Sym (D:R:PrimStateST[0] <s_a3NiN>_N)))_R
:: State# s_a3NiN
~R# State# (PrimState (ST s_a3NiN))))
of
{ (# ipv_amtT [Occ=Once], ipv1_amtU [Occ=Once] #) ->
let {
ipv1_saFXs [Occ=Once]
:: MVector (PrimState (ST s_a3NiN)) Double
[LclId,
Unf=Unf{Src=<vanilla>, TopLvl=False, Value=False,
ConLike=False, WorkFree=False, Expandable=False,
Guidance=IF_ARGS [] 70 0}]
ipv1_saFXs
= $WMV_Double
@ (PrimState (ST s_a3NiN))
($WMVector
@ (PrimState (ST s_a3NiN))
@ Double
f_amtG
(n_s3NzS
`cast` (N:Id[0] <Int>_R :: Id Int ~R# Int))
(MutableByteArray
@ (PrimState (ST s_a3NiN)) ipv1_amtU)) } in
```8.8.2Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/17109path to ghc no longer works in the 8.8.1 build2019-09-14T14:44:38ZSam Hallidaypath to ghc no longer works in the 8.8.1 build## Summary
The flags `--with-ghc` no longer works to build ghc (which breaks `ghcup`) and the suggested replacement to use `GHC` does not work.
I'd personally like to see `--with-ghc` return as it will require a workaround in `ghcup` (...## Summary
The flags `--with-ghc` no longer works to build ghc (which breaks `ghcup`) and the suggested replacement to use `GHC` does not work.
I'd personally like to see `--with-ghc` return as it will require a workaround in `ghcup` (and probably other packaging tools) to support the new system anyway.
## Steps to reproduce
```
$ curl -L --fail -O https://downloads.haskell.org/~ghc/8.8.1/ghc-8.8.1-src.tar.xz
$ cd ghc-8.8.1
$ ./boot
$ GHC=ghc-8.6.5 ./configure --prefix=$HOME/.ghcup/ghc/8.8.1
...
checking for gfind... no
checking for find... /usr/bin/find
checking for sort... /usr/bin/sort
checking for GHC Git commit id... given 9c787d4d24f2b515934c8503ee2bbd7cfac4da20
checking for ghc... no
configure: error: GHC is required.
```
Also, a minor point, but the 8.8.1 tarball required me to install alex/happy whereas this has not been needed for previous versions.
## Expected behavior
Compile ghc.
## Environment
Archlinux.8.8.2https://gitlab.haskell.org/ghc/ghc/-/issues/17114ghc-8.8.1 release tarball requires alex at ./configure time2019-08-27T07:17:56ZSergei Trofimovichghc-8.8.1 release tarball requires alex at ./configure timeGHC release tarballs used not to require `alex` or `happy` and included generated versions of parser and lexer.
`ghc-8.8.1` release tarball seems to be different and fails `./configure` step:
```
./configure
...
checking for happy... ...GHC release tarballs used not to require `alex` or `happy` and included generated versions of parser and lexer.
`ghc-8.8.1` release tarball seems to be different and fails `./configure` step:
```
./configure
...
checking for happy... no
checking for version of happy...
checking for alex... no
checking for version of alex...
configure: error: Alex version 3.1.7 or later is required to compile GHC.
```8.8.2