Runtime panic in CNF test 'compact_gc' when compacting GC is enabled
Program:
import Control.Monad
import GHC.Compact
import qualified Data.Map as Map
main = do
let m = Map.fromList [(x, show x) | x <- [1 .. (10000 :: Int)]]
c <- compactWithSharing m
print =<< compactSize c
c <- foldM (\c _ -> do c <- compactWithSharing (getCompact c)
print =<< compactSize c
return c)
c [1..10]
print (length (show (getCompact c)))
print =<< compactSize c
Run with +RTS -c
:
$ ghc-stage2 test.hs -rtsopts
Linking test ...
$ ./test +RTS -c
test: internal error: scavenge_mark_stack: unimplemented/strange closure type 0 @ 0x420012d5c8
(GHC version 8.11.0.20200319 for x86_64_unknown_linux)
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
zsh: abort (core dumped) ./test +RTS -c
Backtrace:
>>> bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x00007f91e4de7801 in __GI_abort () at abort.c:79
#2 0x0000000000661757 in rtsFatalInternalErrorFn (s=0x23a8cd "invalid closure, info=%p", ap=0x7fffd25b8840) at rts/RtsMessages.c:186
#3 0x000000000066130e in barf (s=0x23a8cd "invalid closure, info=%p") at rts/RtsMessages.c:48
#4 0x000000000069fd5e in evacuate (p=0x7fffd25b89d0) at rts/sm/Evac.c:592
#5 0x000000000069550a in evacuate_hash_entry (dat=0x7fffd25b8a60, key=283469929872, value=0x42001e5c71) at rts/sm/Scav.c:172
#6 0x00000000006771a6 in mapHashTable (table=0x12b6810, data=0x7fffd25b8a60, fn=0x6954d3 <evacuate_hash_entry>) at rts/Hash.c:458
#7 0x00000000006955b2 in scavenge_compact (str=0x42001f5018) at rts/sm/Scav.c:192
#8 0x0000000000697a7b in scavenge_one (p=0x42001f5018) at rts/sm/Scav.c:1561
#9 0x00000000006983e8 in scavenge_large (ws=0x827d80 <the_gc_thread+320>) at rts/sm/Scav.c:2016
#10 0x0000000000698556 in scavenge_find_work () at rts/sm/Scav.c:2086
#11 0x000000000069861c in scavenge_loop () at rts/sm/Scav.c:2155
#12 0x0000000000691fe4 in scavenge_until_all_done () at rts/sm/GC.c:1175
#13 0x0000000000690990 in GarbageCollect (collect_gen=1, do_heap_census=false, deadlock_detect=false, gc_type=0, cap=0x826500 <MainCapability>, idle_cap=0x0) at rts/sm/GC.c:449
#14 0x0000000000668cbf in scheduleDoGC (pcap=0x7fffd25b8f78, task=0x1217db0, force_major=false, deadlock_detect=false) at rts/Schedule.c:1855
#15 0x00000000006681e6 in schedule (initialCapability=0x826500 <MainCapability>, task=0x1217db0) at rts/Schedule.c:565
#16 0x00000000006696b7 in scheduleWaitThread (tso=0x4200105388, ret=0x0, pcap=0x7fffd25b9080) at rts/Schedule.c:2600
#17 0x000000000067ad18 in rts_evalLazyIO (cap=0x7fffd25b9080, p=0x6cb338, ret=0x0) at rts/RtsAPI.c:530
#18 0x000000000067b4bd in hs_main (argc=1, argv=0x7fffd25b9278, main_closure=0x6cb338, rts_config=...) at rts/RtsMain.c:72
#19 0x0000000000254034 in main ()
This happens pretty reliably, every run.
If I also pass -DS
I get the same panic. Assuming -DS
checks compact regions
correctly, this means that the bug caught in the same GC that breaks the
invariants/data structures or causes heap corruption.