[GHC] #16057: GHC 8.6.3 hangs with Template Haskell on Windows 10

[GHC]

#16057: GHC 8.6.3 hangs with Template Haskell on Windows 10
-------------------------------------+-------------------------------------
        Reporter:  gizmo.mk0         |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  highest           |            Milestone:
       Component:  Template Haskell  |              Version:  8.6.3
      Resolution:                    |             Keywords:
Operating System:  Windows           |         Architecture:  x86
 Type of failure:  Compile-time      |            Test Case:
  crash or panic                     |
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------
Changes (by Phyx-):

 * priority:  normal => highest


Comment:

 Bisected to `ed86e3b531322f74d2c2d00d7ff8662b08fabde6`. Now the question
 is why.. rebuilding stage2 without rebuilding any of the libs works..

 The change somehow causes an invalid info table to be created, this
 triggers a segfault

 {{{
 Thread 1 received signal SIGSEGV, Segmentation fault.
 0x0000000002dc3602 in interpretBCO (cap=0x36da520 <MainCapability>)
     at rts\Interpreter.c:395
 395         switch ( get_itbl(obj)->type ) {
 }}}

 Which jumps to the signal handlers, which try to recover from the error in
 order to print the call stack, and ends up triggering the segfault again.
 Causing the infinite loop.

 The signal handler looping I have a patch for that I will upstream next
 week (need to split it from another patch), however the question is why
 the info table becomes invalid with this patch..

 {{{
 (gdb) p *obj
 $1 = {header = {info = 0xec003ac00000000}, payload = 0xec004d8}
 (gdb) p obj->info
 There is no member named info.
 (gdb) p obj->header.info
 $2 = (const StgInfoTable *) 0xec003ac00000000
 (gdb) p *obj->header.info
 Cannot access memory at address 0xec003ac00000000
 }}}

 Note that this doesn't fail in HEAD, so I don't think the change is actual
 cause.. Just exposing it.

 Another question remains.. do we not have any actual TH tests in the
 testsuite???

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