#12501: Windows builds segfault (as in doesn't work at all). -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: | Type of failure: GHC doesn't work Unknown/Multiple | at all Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Commit a9bc54766ddd1bdb011f1656ad58fb409055d08f 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 cf989ffe490c146be4ed0fd7e0c00d3ff8fe1453 but fixed by f9a11a241b8056ac2b9c771172a48919fb3d0ed1 Unfortunately because many of the intermediate commits between cf989ffe490c146be4ed0fd7e0c00d3ff8fe1453 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 ) at rts\sm\Evac.c:416 #2 0x0000000002a7a183 in scavenge_srt (srt=0x31c1a04 , srt_bitmap=1) at rts\sm\Scav.c:351 #3 0x0000000002a7a253 in scavenge_fun_srt (info=0x278dfb0 ) 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 , ret=0x0) at rts\RtsAPI.c:500 #12 0x0000000002a4d350 in hs_main (argc=1, argv=0x6c640b0, main_closure=0x2aabad0 , 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 (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 ""} }}} 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. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12501 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler