I replaced the code below because I found a much much smaller reproduction.
code\Only-0.1 via λ 9.8.1
❯ /c/ghcup/bin/ghc-9.8.1 -fforce-recomp src/Data/Tuple/Only.hs -XHaskell2010
[1 of 1] Compiling Data.Tuple.Only ( src\Data\Tuple\Only.hs, src\Data\Tuple\Only.o )
code\Only-0.1 via λ 9.8.1
➜ /c/ghcup/bin/ghc-9.8.1 -fforce-recomp src/Data/Tuple/Only.hs -O
[1 of 1] Compiling Data.Tuple.Only ( src\Data\Tuple\Only.hs, src\Data\Tuple\Only.o )
code\Only-0.1 via λ 9.8.1
➜ /c/ghcup/bin/ghc-9.8.1 -fforce-recomp src/Data/Tuple/Only.hs -XHaskell2010 -O
[1 of 1] Compiling Data.Tuple.Only ( src\Data\Tuple\Only.hs, src\Data\Tuple\Only.o )
ghc-9.8.1.exe: heap overflow
code\Only-0.1 via λ 9.8.1
➜ cat src/Data/Tuple/Only.hs
{-# LANGUAGE DeriveDataTypeable #-}
module Data.Tuple.Only where
import Data.Data (Data)
data Only a = Only deriving (Data)
ghcup install ghc 9.8.1 --set
ghcup install cabal 3.10.2.1 --set
cat <<EOF > Only.hs
{-# LANGUAGE DeriveDataTypeable #-}
module Only where
import Data.Data (Data)
data Only a = Only deriving (Data)
EOF
ghc Only.hs -XHaskell2010 -O
Optional:
MINGW64_NT-10.0-22631 ... 3.4.10.x86_64 2023-12-22 10:06 UTC x86_64 Msys
Weirdly enough, I reinstalled 9.8.1 and this is no longer happening. Let’s just close it.
It doesn't loop. It crashes immediately.
➜ /usr/bin/time -v /c/ghcup/bin/ghc-9.8.1 -fforce-recomp src/Data/Tuple/Only.hs -XHaskell2010 -O -v3
Glasgow Haskell Compiler, Version 9.8.1, stage 2 booted by GHC version 9.4.3
*** initializing unit database:
package flags []
loading package database C:\ghcup\ghc\9.8.1\lib\package.conf.d
wired-in package ghc-prim mapped to ghc-prim-0.11.0-6ef2
wired-in package ghc-bignum mapped to ghc-bignum-1.3-7ca5
wired-in package base mapped to base-4.19.0.0-1e7d
wired-in package rts mapped to rts-1.0.2
wired-in package template-haskell mapped to template-haskell-2.21.0.0-9348
!!! initializing unit database: finished in 0.00 milliseconds, allocated 1.934 megabytes
*** Chasing dependencies:
Chasing modules from: main:src\Data\Tuple\Only.hs
!!! Chasing dependencies: finished in 15.63 milliseconds, allocated 2.074 megabytes
Ready for upsweep [SingleModule(main:Data.Tuple.Only [])]
compile: input file src\Data\Tuple\Only.hs
*** Checking old interface for Data.Tuple.Only (use -ddump-hi-diffs for more details):
[1 of 1] Compiling Data.Tuple.Only ( src\Data\Tuple\Only.hs, src\Data\Tuple\Only.o )
*** Parser [Data.Tuple.Only]:
!!! Parser [Data.Tuple.Only]: finished in 0.00 milliseconds, allocated 0.216 megabytes
*** Renamer/typechecker [Data.Tuple.Only]:
ghc-9.8.1.exe: heap overflow
*** Deleting temp files:
Deleting:
*** Deleting temp subdirs:
Deleting:
*** Deleting temp dirs:
Deleting:
Command exited with non-zero status 1
Command being timed: "/c/ghcup/bin/ghc-9.8.1 -fforce-recomp src/Data/Tuple/Only.hs -XHaskell2010 -O -v3"
User time (seconds): 0.00
System time (seconds): 0.00
Percent of CPU this job got: 0%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.19
Average shared text size (kbytes): 0
Average unshared data size (kbytes): 0
Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 4988
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 1316
Minor (reclaiming a frame) page faults: 0
Voluntary context switches: 0
Involuntary context switches: 0
Swaps: 0
File system inputs: 0
File system outputs: 0
Socket messages sent: 0
Socket messages received: 0
Signals delivered: 0
Page size (bytes): 65536
Exit status: 1
It turns out that the combination of -O -XHaskell2010 -XPolyKinds
succeeds, whereas -O -XHaskell2010
doesn't.
Indeed!
code\Only-0.1 via λ 9.8.1
❯ /c/ghcup/bin/ghc-9.8.1 -fforce-recomp src/Data/Tuple/Only.hs -XHaskell2010
[1 of 1] Compiling Data.Tuple.Only ( src\Data\Tuple\Only.hs, src\Data\Tuple\Only.o )
code\Only-0.1 via λ 9.8.1
➜ /c/ghcup/bin/ghc-9.8.1 -fforce-recomp src/Data/Tuple/Only.hs -O
[1 of 1] Compiling Data.Tuple.Only ( src\Data\Tuple\Only.hs, src\Data\Tuple\Only.o )
code\Only-0.1 via λ 9.8.1
➜ /c/ghcup/bin/ghc-9.8.1 -fforce-recomp src/Data/Tuple/Only.hs -XHaskell2010 -O
[1 of 1] Compiling Data.Tuple.Only ( src\Data\Tuple\Only.hs, src\Data\Tuple\Only.o )
ghc-9.8.1.exe: heap overflow
code\Only-0.1 via λ 9.8.1
➜ cat src/Data/Tuple/Only.hs
{-# LANGUAGE DeriveDataTypeable #-}
module Data.Tuple.Only where
import Data.Data (Data)
data Only a = Only deriving (Data)
So I have a much smaller reproduction:
{-# LANGUAGE DeriveDataTypeable #-}
module Data.Tuple.Only where
import Data.Data (Data)
data Only a = Only deriving (Data)
This will:
-O
)ghc-9.8.1 Only.hs -fforce-recomp
)-O
from the options-O
and provide -ddump-tc-trace
The output is quite verbose, I'll leave it in an attached file, It's the output of running this:
#!/usr/bin/env sh
# The cabal options found via `-v2` minus `-O`
OPTIONS="--make -fbuilding-cabal-package -outputdir /c/Users/Javier/code/cardano/Only-0.1/dist-newstyle/build/x86_64-windows/ghc-9.8.1/Only-0.1/build -odir /c/Users/Javier/code/cardano/Only-0.1/dist-newstyle/build/x86_64-windows/ghc-9.8.1/Only-0.1/build -hidir /c/Users/Javier/code/cardano/Only-0.1/dist-newstyle/build/x86_64-windows/ghc-9.8.1/Only-0.1/build -stubdir /c/Users/Javier/code/cardano/Only-0.1/dist-newstyle/build/x86_64-windows/ghc-9.8.1/Only-0.1/build -i -i/c/Users/Javier/code/cardano/Only-0.1/dist-newstyle/build/x86_64-windows/ghc-9.8.1/Only-0.1/build -isrc -i/c/Users/Javier/code/cardano/Only-0.1/dist-newstyle/build/x86_64-windows/ghc-9.8.1/Only-0.1/build/autogen -i/c/Users/Javier/code/cardano/Only-0.1/dist-newstyle/build/x86_64-windows/ghc-9.8.1/Only-0.1/build/global-autogen -I/c/Users/Javier/code/cardano/Only-0.1/dist-newstyle/build/x86_64-windows/ghc-9.8.1/Only-0.1/build/autogen -I/c/Users/Javier/code/cardano/Only-0.1/dist-newstyle/build/x86_64-windows/ghc-9.8.1/Only-0.1/build/global-autogen -I/c/Users/Javier/code/cardano/Only-0.1/dist-newstyle/build/x86_64-windows/ghc-9.8.1/Only-0.1/build -I/c/msys64/ucrt64/include -optP-include -optP/c/Users/Javier/code/cardano/Only-0.1/dist-newstyle/build/x86_64-windows/ghc-9.8.1/Only-0.1/build/autogen/cabal_macros.h -this-unit-id Only-0.1-inplace -Wmissing-home-modules -no-user-package-db -package-db /c/Users/Javier/AppData/Local/cabal/store/ghc-9.8.1/package.db -package-db /c/Users/Javier/code/cardano/Only-0.1/dist-newstyle/packagedb/ghc-9.8.1 -package-db /c/Users/Javier/code/cardano/Only-0.1/dist-newstyle/build/x86_64-windows/ghc-9.8.1/Only-0.1/package.conf.inplace -package-id deepseq-1.5.0.0-940f -XHaskell2010 Data.Tuple.Only"
# fails
/c/ghcup/bin/ghc-9.8.1 -fforce-recomp $OPTIONS -O
printf "\n\n\n"
# succeeds
/c/ghcup/bin/ghc-9.8.1 -fforce-recomp src/Data/Tuple/Only.hs -O
printf "\n\n\n"
# succeeds
/c/ghcup/bin/ghc-9.8.1 -fforce-recomp $OPTIONS
printf "\n\n\n"
# fails
/c/ghcup/bin/ghc-9.8.1 -fforce-recomp $OPTIONS -ddump-tc-trace
I replaced the code below because I found a much much smaller reproduction.
code\Only-0.1 via λ 9.8.1
❯ /c/ghcup/bin/ghc-9.8.1 -fforce-recomp src/Data/Tuple/Only.hs -XHaskell2010
[1 of 1] Compiling Data.Tuple.Only ( src\Data\Tuple\Only.hs, src\Data\Tuple\Only.o )
code\Only-0.1 via λ 9.8.1
➜ /c/ghcup/bin/ghc-9.8.1 -fforce-recomp src/Data/Tuple/Only.hs -O
[1 of 1] Compiling Data.Tuple.Only ( src\Data\Tuple\Only.hs, src\Data\Tuple\Only.o )
code\Only-0.1 via λ 9.8.1
➜ /c/ghcup/bin/ghc-9.8.1 -fforce-recomp src/Data/Tuple/Only.hs -XHaskell2010 -O
[1 of 1] Compiling Data.Tuple.Only ( src\Data\Tuple\Only.hs, src\Data\Tuple\Only.o )
ghc-9.8.1.exe: heap overflow
code\Only-0.1 via λ 9.8.1
➜ cat src/Data/Tuple/Only.hs
{-# LANGUAGE DeriveDataTypeable #-}
module Data.Tuple.Only where
import Data.Data (Data)
data Only a = Only deriving (Data)
ghcup install ghc 9.8.1 --set
ghcup install cabal 3.10.2.1 --set
cat <<EOF > Only.hs
{-# LANGUAGE DeriveDataTypeable #-}
module Only where
import Data.Data (Data)
data Only a = Only deriving (Data)
EOF
ghc Only.hs -XHaskell2010 -O
Optional:
MINGW64_NT-10.0-22631 ... 3.4.10.x86_64 2023-12-22 10:06 UTC x86_64 Msys
An even simpler example with base
itself:
cabal-version: 3.0
name: aa
version: 0.1.0.0
library
exposed-modules: MyLib
build-depends: base ^>=4.18.1.0
hs-source-dirs: src
default-language: Haskell2010
mixins: base hiding (Control.Exception)
Results in:
❯ cabal build --ghc-option=-Werror=unused-packages
Resolving dependencies...
Build profile: -w ghc-9.6.3 -O1
In order, the following will be built (use -v for more details):
- aa-0.1.0.0 (lib) (configuration changed)
Configuring library for aa-0.1.0.0..
Preprocessing library for aa-0.1.0.0..
Building library for aa-0.1.0.0..
<no location info>: error: [GHC-42258] [-Wunused-packages, Werror=unused-packages]
The following packages were specified via -package or -package-id flags,
but were not needed for compilation:
- base-4.18.1.0 (exposed by flag -package-id base-4.18.1.0)
Error: cabal-3.10.2.0: Failed to build aa-0.1.0.0.
Javier Sagredo (285f5fd4) at 28 Nov 19:23
Remove redundant if-then-else on setupUpdate
Order of debug options and eventlog result in unexpected behavior.
-Dm
: emits messages -Dm
to stderr -Dm -l
: emits messages -Dm
to the eventlog -l -Dm
: emits -Dm
to stderr and enables what I believe is -Ds
Any program would suffice. I can provide this one:
$ cat A.hs
module Main where
{-# NOINLINE fib #-}
fib 0 = 0
fib 1 = 1
fib n = fib (n-1) + fib (n-2)
main = do
print (fib 30)
$ ghc A.hs -debug
[1 of 2] Compiling Main ( A.hs, A.o )
[2 of 2] Linking A [Objects changed]
$ ./A +RTS -Dm 2>&1 | head
STM: 0x5b0780 : lock_stm()
STM: stmPreGCHook
STM: 0x5b0780 : unlock_stm()
STM: 0x5b0780 : lock_stm()
STM: stmPreGCHook
STM: 0x5b0780 : unlock_stm()
STM: 0x5b0780 : lock_stm()
STM: stmPreGCHook
STM: 0x5b0780 : unlock_stm()
STM: 0x5b0780 : lock_stm()
$ ./A +RTS -l -Dm 2>&1 | head
created capset 0 of type 2
created capset 1 of type 3
cap 0: initialised
assigned cap 0 to capset 0
assigned cap 0 to capset 1
cap 0: created thread 1[""]
cap 0: running thread 1[""] (ThreadRunGHC)
cap 0: thread 1[""] stopped (stack overflow, size 104)
cap 0: running thread 1[""] (ThreadRunGHC)
cap 0: thread 1[""] stopped (yielding)
$ ./A +RTS -Dm -l 2>&1 | head
832040
I would expect -Ds
not to be enabled by this combination of flags, and furthermore I though the order of the options should not modify the behaviour.
Optional:
Golden files have been modified (thanks @BinderDavid) and the commit message amended. I think this should be good to go.
Javier Sagredo (a97e8868) at 21 Oct 11:41
Profiling: Adds an option to not start time profiling at startup
I modified the title with your suggestion. Once there is agreement on the contents of the MR or if in the meantime I have to fixup the commit, I can also fix the commit message with the same suggestion.
I also saw that a test case is failing, I think from what I could read that it is kind of a “golden” output of the RTS flags, so that should be easy to fix.
My other two concerns are:
since
field in the RTS flags section of the user guideI have, with a very trivial example (although the patch was wrong, I pushed a new version):
❯ cat A.hs
module Main where
import GHC.Profiling
{-# NOINLINE fib #-}
fib 0 = 0
fib 1 = 1
fib n = fib (n-1) + fib (n-2)
{-# NOINLINE fab #-}
fab 0 = 0
fab 1 = 1
fab n = fab (n-1) + fab (n-2)
{-# NOINLINE feb #-}
feb 0 = 0
feb 1 = 1
feb n = feb (n-1) + feb (n-2)
{-# NOINLINE fob #-}
fob 0 = 0
fob 1 = 1
fob n = fob (n-1) + fob (n-2)
main = do
print (fib 30)
startProfTimer
print (fab 30)
stopProfTimer
print (feb 30)
startProfTimer
print (fob 30)
❯ ./ghc/_build/ghc-stage1 A.hs -prof -fprof-auto -fforce-recomp
[1 of 2] Compiling Main ( A.hs, A.o )
[2 of 2] Linking A [Objects changed]
❯ cat A.prof
Mon Oct 9 18:55 2023 Time and Allocation Profiling Report (Final)
A +RTS -p --no-automatic-time-samples -RTS
total time = 0.80 secs (798 ticks @ 1000 us, 1 processor)
total alloc = 2,297,380,872 bytes (excludes profiling overheads)
COST CENTRE MODULE SRC %time %alloc
fab Main A.hs:(11,1)-(13,29) 50.4 25.0
fob Main A.hs:(21,1)-(23,29) 49.6 25.0
fib Main A.hs:(6,1)-(8,29) 0.0 25.0
feb Main A.hs:(16,1)-(18,29) 0.0 25.0
individual inherited
COST CENTRE MODULE SRC no. entries %time %alloc %time %alloc
MAIN MAIN <built-in> 137 0 0.0 0.0 100.0 100.0
CAF Main <entire-module> 273 0 0.0 0.0 100.0 100.0
main Main A.hs:(25,1)-(32,16) 274 1 0.0 0.0 100.0 100.0
fab Main A.hs:(11,1)-(13,29) 277 2692537 50.4 25.0 50.4 25.0
feb Main A.hs:(16,1)-(18,29) 278 2692537 0.0 25.0 0.0 25.0
fib Main A.hs:(6,1)-(8,29) 276 2692537 0.0 25.0 0.0 25.0
fob Main A.hs:(21,1)-(23,29) 279 2692537 49.6 25.0 49.6 25.0
CAF GHC.Conc.Signal <entire-module> 268 0 0.0 0.0 0.0 0.0
CAF GHC.IO.Encoding <entire-module> 258 0 0.0 0.0 0.0 0.0
CAF GHC.IO.Encoding.Iconv <entire-module> 256 0 0.0 0.0 0.0 0.0
CAF GHC.IO.Handle.FD <entire-module> 248 0 0.0 0.0 0.0 0.0
main Main A.hs:(25,1)-(32,16) 275 0 0.0 0.0 0.0 0.0
Javier Sagredo (dbd55766) at 09 Oct 16:53
Profiling: Allow time profiling to be controlled dynamically.
Javier Sagredo (ca4bff4d) at 09 Oct 15:10
Profiling: Allow time profiling to be controlled dynamically.
I am unsure of several things here:
since
flag, what should I set it to?This patch adds a RTS flag (--no-automatic-time-samples
) which allows the program to start without starting the time profiling, in the same spirit as d89deeba did for heap profiling.
Please take a few moments to address the following points:
base
or causes the
compiler to reject programs), please describe the expected breakage and add
the ~"user-facing" label. This will run ghc/head.hackage> to characterise
the effect of your change on Hackage.#NNNN
syntax when appropriate)Javier Sagredo (43746d5f) at 09 Oct 15:02
Profiling: Allow time profiling to be controlled dynamically.