Windows builds segfault (as in doesn't work at all).
Commit a9bc5476 is the last known good commit for the Windows build of GHC.
After this point multiple segfaults were introduced due to changes in the rts and GC.
One was introduced by the compacts regions patch cf989ffe but fixed by f9a11a24
Unfortunately because many of the intermediate commits between cf989ffe also break the build I can't run a proper bisect. And because of some very large commits in between it makes it really hard to cherry-pick individual commits or rebase certain ones out manually to try.
Effectively something was committed that makes GC go horribly wrong.
Tamar@Kino MINGW64 ~/ghc2
$ inplace/bin/ghc-stage2.exe --version
The Glorious Glasgow Haskell Compilation System, version 8.1.20160817
Segmentation fault
In GDB
Program received signal SIGSEGV, Segmentation fault.
0x0000000002aa35d9 in LOOKS_LIKE_CLOSURE_PTR (p=0x2cd1dd000000000) at includes/rts/storage/ClosureMacros.h:275
275 (UNTAG_CONST_CLOSURE((const StgClosure *)(p)))->header.info);
(gdb) bt
#0 0x0000000002aa35d9 in LOOKS_LIKE_CLOSURE_PTR (p=0x2cd1dd000000000) at includes/rts/storage/ClosureMacros.h:275
#1 0x0000000002aa3e3e in evacuate1 (p=0x31c1a04 <S4UR_srt+4>) at rts\sm\Evac.c:416
#2 0x0000000002a7a183 in scavenge_srt (srt=0x31c1a04 <S4UR_srt+4>, srt_bitmap=1) at rts\sm\Scav.c:351
#3 0x0000000002a7a253 in scavenge_fun_srt (info=0x278dfb0 <c1Fi_info+88>) at rts\sm\Scav.c:390
#4 0x0000000002a7c245 in scavenge_static () at rts\sm\Scav.c:1747
#5 0x0000000002a7c8f2 in scavenge_loop1 () at rts\sm\Scav.c:2081
#6 0x0000000002a722bb in scavenge_until_all_done () at rts\sm\GC.c:968
#7 0x0000000002a71008 in GarbageCollect (collect_gen=1, do_heap_census=rtsFalse, gc_type=2, cap=0x320f5c0 <MainCapability>) at rts\sm\GC.c:403
#8 0x0000000002a61856 in scheduleDoGC (pcap=0x3b4fbb8, task=0x6c6e0d0, force_major=rtsFalse) at rts\Schedule.c:1797
#9 0x0000000002a5fb68 in schedule (initialCapability=0x320f5c0 <MainCapability>, task=0x6c6e0d0) at rts\Schedule.c:552
#10 0x0000000002a62355 in scheduleWaitThread (tso=0x7205b98, ret=0x0, pcap=0x3b4fd40) at rts\Schedule.c:2494
#11 0x0000000002a4e24a in rts_evalLazyIO (cap=0x3b4fd40, p=0x2aabad0 <ZCMain_main_closure>, ret=0x0) at rts\RtsAPI.c:500
#12 0x0000000002a4d350 in hs_main (argc=1, argv=0x6c640b0, main_closure=0x2aabad0 <ZCMain_main_closure>, rts_config=...) at rts\RtsMain.c:64
#13 0x00000000004b4c75 in main ()
It seems that all info
tables are messed up.
In frame #4
the table contains very suspicious values:
(gdb) frame 4
#4 0x0000000002a7c245 in scavenge_static () at rts\sm\Scav.c:1747
1747 scavenge_fun_srt(info);
(gdb) p info
$3 = (const StgInfoTable *) 0x278dfb0 <c1Fi_info+88>
(gdb) pinfo info
$4 = {layout = {payload = {ptrs = 10697284, nptrs = 0}, bitmap = 10697284, large_bitmap_offset = 10697284, __pad_large_bitmap_offset = 10697284, selector_offset = 10697284}, type = 3, srt_bitmap = 1, code = 0x278dfb0 <c1Fi_info+88> ""}
Unfortunately my knowledge of GHC's GC
is severely lacking at this moment so I have no idea how to debug this effectively and without knowing the commit that introduced it's rather slow going.
Any help or hints appreciated.
Trac metadata
Trac field | Value |
---|---|
Version | 8.0.1 |
Type | Bug |
TypeOfFailure | OtherFailure |
Priority | highest |
Resolution | Unresolved |
Component | Compiler |
Test case | |
Differential revisions | |
BlockedBy | |
Related | |
Blocking | |
CC | |
Operating system | |
Architecture |