#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