[GHC] #12501: Windows builds segfault (as in doesn't work at all).

[GHC]

#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 at 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.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12501>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler