#14675: GHC 8.4.1 regression: segfault when loading doctest on a module with ANNs on Ubuntu 16.04 or later -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: GHC API | Version: 8.4.1-alpha1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Thanks, as always, for the bisection Ryan; it's incredibly helpful. I wonder if this is related to the `gold` bug that I found while writing that patch (see #13883). It seems plausible that constructor mis-ordering would result in a crash. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14675#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#14675: GHC 8.4.1 regression: segfault when loading doctest on a module with ANNs on Ubuntu 16.04 or later -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: GHC API | Version: 8.4.1-alpha1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #14603 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alpmestan): I started taking a look at this. First, I haven't been able to reproduce the issue on NixOS. So I started toying around in an Ubuntu 16.04 virtual machine, on which I installed ghc 8.2.2 and 8.4.1, both from hvr's PPA. And I can indeed reproduce the segmentation fault, only with 8.4.1 just like you. However, I started thinking that it might be nice to be able to use gdb to see exactly what code is being executed when the segfault happens. Then I built both the same commit from which hvr's ghc-8.4.1 was built as well as the tip of the 8.4.1 alpha1 branch, both with the quick flavour, the --enable-dwarf-unwind configure option and -g3 for the libs and the RTS. Now, for the fun part: I have _not_ been able to reproduce the bug with those builds of GHC. I'll start looking into the Debian build recipes used by hvr's PPA, with the hope of being able to build a gdb-friendly clone of hvr's 8.4.1 build that does have the bug but also allows me to look around right before it happens. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14675#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#14675: GHC 8.4.1 regression: segfault when loading doctest on a module with ANNs on Ubuntu 16.04 or later -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: alpmestan Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: GHC API | Version: 8.4.1-alpha1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #14603 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I wonder if the version of `ld.gold` has something to do with this? On Ubuntu 14.04, I have: {{{ $ ld.gold --version GNU gold (GNU Binutils for Ubuntu 2.24) 1.11 Copyright 2013 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty. }}} But on Ubuntu 16.04 and later, I have: {{{ $ ld.gold --version GNU gold (GNU Binutils for Ubuntu 2.28) 1.14 Copyright (C) 2017 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty. }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14675#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#14675: GHC 8.4.1 regression: segfault when loading doctest on a module with ANNs on Ubuntu 16.04 or later -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: alpmestan Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: GHC API | Version: 8.4.1-alpha1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #14603 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Well, you can check what `"ld command"` is on the respective `settings` files (e.g., `/opt/ghc/8.2.2/lib/ghc-8.2.2/settings` and `/opt/ghc/8.4.1/lib/ghc-8.4.0.20171222/settings`) to be sure (in my case, it's `ld.gold` for both). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14675#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#14675: GHC 8.4.1 regression: segfault when loading doctest on a module with ANNs on Ubuntu 16.04 or later -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: alpmestan Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: GHC API | Version: 8.4.1-alpha1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #14603 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Ah, darn, never mind then :) I'm not sure if there's an easier way to pinpoint differences between individual components of Ubuntu 14.04 vs. 16.04 that might be contributing to this... perhaps Nix makes this easier? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14675#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#14675: GHC 8.4.1 regression: segfault when loading doctest on a module with ANNs on Ubuntu 16.04 or later -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: alpmestan Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: GHC API | Version: 8.4.1-alpha1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #14603 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alpmestan): I ended up chasing down the problem with `gdb` a little bit but didn't really know where to break and stepping through everything was just not conceivable so I ended up going about it the good old way, by printing a bunch of things along the code path that leads to the error. Long story short, it looks like the `unsafeCoerce#` from `compiler/typecheck/TcSplice.hs:convertAnnotationWrapper` is the cause of the segfault. And the content of the annotation doesn't seem to matter, even `{-# ANN module () #-}` makes the program crash. You can see [https://gist.github.com/alpmestan/145fc5783f00bab9214b7302418aef49 here] my variant of `convertAnnotationWrapper` that prints a bunch of things all along, as well as the relevant section of the output (the "trace"). The program never makes it to "unsafeCoerce# went fine". I will next try to look into what the value we're coercing actually represents and why it's not what we expect. If anyone has any tips for figuring that out quickly, I'm all ears :) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14675#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#14675: GHC 8.4.1 regression: segfault when loading doctest on a module with ANNs on Ubuntu 16.04 or later -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: alpmestan Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: GHC API | Version: 8.4.1-alpha1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #14603 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alpmestan): I can reproduce with a `prof`-flavoured GHC, yes. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14675#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#14675: GHC 8.4.1 regression: segfault when loading doctest on a module with ANNs on Ubuntu 16.04 or later -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: alpmestan Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: GHC API | Version: 8.4.1-alpha1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #14603 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alpmestan): Below is a summary of how things go in `interpretBCO`. Here's how things look when we enter that function: {{{#!c (gdb) x/8a $rbp 0x7fffffffe0f0: 0x7fffffffe140 0x2cc3186 0x7fffffffe100: 0x33e7d40 0x33c7ac0 <MainCapability> 0x7fffffffe110: 0x33c7ac0 <MainCapability> 0x2cc73fd 0x7fffffffe120: 0x33c7ad8 0x2033c7ac0 (gdb) x/8a Sp 0x42001fcb28: 0x2cf4728 0x42003b2e70 0x42001fcb38: 0x2cf34e8 0x42003b2eb0 0x42001fcb48: 0x10202e0 0x2cf34e8 0x42001fcb58: 0x420012ec20 0x2cf34e8 (gdb) ghc closure 0x42003b2e70 BCO (gdb) ghc closure 0x42003b2eb0 AP(0x42003b2e70) }}} This leads us to entering this block from `interpretBCO`: {{{#!c else if (SpW(0) == (W_)&stg_apply_interp_info) { obj = UNTAG_CLOSURE((StgClosure *)SpW(1)); Sp_addW(2); goto run_BCO_fun; } }}} We successfully retrieve `obj`, which is a `BCO`: {{{#!c (gdb) 0x0000000002cc8c62 in interpretBCO (cap=0x33c7ac0 <MainCapability>) at rts/Interpreter.c:354 354 obj = UNTAG_CLOSURE((StgClosure *)SpW(1)); (gdb) 355 Sp_addW(2); (gdb) print obj $5 = (StgClosure *) 0x42003b2e70 (gdb) ghc closure obj BCO }}} We then jump to `run_BCO_fun` (see [https://github.com/ghc/ghc/blob/cca2d6b78f97bfb79bef4dc3f75d6c4d15b94680/rts... here]). The stack & heap checks go well and we jump straight to `run_BCO` (right below `run_BCO_fun` in the source code), which starts like this {{{#!c register int bciPtr = 0; /* instruction pointer */ register StgWord16 bci; register StgBCO* bco = (StgBCO*)obj; register StgWord16* instrs = (StgWord16*)(bco->instrs->payload); register StgWord* literals = (StgWord*)(&bco->literals->payload[0]); register StgPtr* ptrs = (StgPtr*)(&bco->ptrs->payload[0]); #if defined(DEBUG) int bcoSize; bcoSize = bco->instrs->bytes / sizeof(StgWord16); }}} {{{#!c (gdb) print bcoSize $14 = 8 (gdb) print (*instrs)@8 $16 = {11, 0, 11, 1, 32, 11, 2, 58} }}} The `ptrs` and `literals` field among others seem to have been optimized out. And we then start processing the instructions. For reference, the opcodes for instructions are defined [https://github.com/ghc/ghc/blob/cca2d6b78f97bfb79bef4dc3f75d6c4d15b94680/inc... here]. {{{#!c bci = BCO_NEXT; /* ... */ switch (bci & 0xFF) { }}} {{{#!c (gdb) print bci $15 = 11 }}} `11 & 0xFF = 11`, which is `bci_PUSH_G`. Here's how it's handled: {{{#!c case bci_PUSH_G: { int o1 = BCO_GET_LARGE_ARG; SpW(-1) = BCO_PTR(o1); Sp_subW(1); goto nextInsn; } /* definitions for the macros: */ #define BCO_GET_LARGE_ARG ((bci & bci_FLAG_LARGE_ARGS) ? BCO_READ_NEXT_WORD : BCO_NEXT) #define bci_FLAG_LARGE_ARGS 0x8000 #define BCO_PTR(n) (W_)ptrs[n] }}} In our case, `bci = 11`, `11 & 0x8000 = 0` so we get `BCO_NEXT` which just reads the next instruction. In our case, `o1 = 0`, so we get the first `StgMutArrPtrs` that comes with the BCO (`gdb` won't let me look at them, it says the value has been optimized out), we push the address on the stack and move to the next instruction, `11` (`bci_PUSH_G` again). This time, `o1 = 1`. We proceed as before but with the second `StgMutArrPtrs`. We end up with: {{{#!c (gdb) x/8a Sp 0x42001fcb28: 0x407a0540 0x401618a8 0x42001fcb38: 0x2cf34e8 0x42003b2eb0 0x42001fcb48: 0x10202e0 0x2cf34e8 0x42001fcb58: 0x420012ec20 0x2cf34e8 }}} We read the next instruction, `bci = 32`, which is, as you can see [https://github.com/ghc/ghc/blob/cca2d6b78f97bfb79bef4dc3f75d6c4d15b94680/inc... here]: {{{#!c #define bci_PUSH_APPLY_PP 32 }}} This leads us to this bit of code in `interpretBCO`: {{{#!c case bci_PUSH_APPLY_PP: Sp_subW(1); SpW(0) = (W_)&stg_ap_pp_info; goto nextInsn; }}} After executing this code, we have, as expected: {{{#!c (gdb) x/8a Sp 0x42001fcb20: 0x2cfa6a0 0x407a0540 0x42001fcb30: 0x401618a8 0x2cf34e8 0x42001fcb40: 0x42003b2eb0 0x10202e0 0x42001fcb50: 0x2cf34e8 0x420012ec20 }}} The next instruction is `11`, so `bci_PUSH_G` again. This time, `o1 = 2` and: {{{#!c (gdb) x/8a Sp 0x42001fcb18: 0x407c6c20 0x2cfa6a0 0x42001fcb28: 0x407a0540 0x401618a8 0x42001fcb38: 0x2cf34e8 0x42003b2eb0 0x42001fcb48: 0x10202e0 0x2cf34e8 }}} Next instruction, `bci = 58`, [https://github.com/ghc/ghc/blob/cca2d6b78f97bfb79bef4dc3f75d6c4d15b94680/inc... which is]: {{{#!c #define bci_ENTER 58 }}} and brings us to this code: {{{#!c case bci_ENTER: // Context-switch check. We put it here to ensure that // the interpreter has done at least *some* work before // context switching: sometimes the scheduler can invoke // the interpreter with context_switch == 1, particularly // if the -C0 flag has been given on the cmd line. if (cap->r.rHpLim == NULL) { Sp_subW(1); SpW(0) = (W_)&stg_enter_info; RETURN_TO_SCHEDULER(ThreadInterpret, ThreadYielding); } goto eval; }}} In our case, `cap->r.rHpLim` is not null and we hit the `goto`, bringing us [https://github.com/ghc/ghc/blob/cca2d6b78f97bfb79bef4dc3f75d6c4d15b94680/rts... here]. {{{#!c eval: tagged_obj = (StgClosure*)SpW(0); Sp_addW(1); eval_obj: obj = UNTAG_CLOSURE(tagged_obj); // ... to be continued ... }}} `gdb` (well, Ben's gdb plugin) reports this closure as off-heap. We then get to: {{{#!c switch ( get_itbl(obj)->type ) { }}} and in our case: {{{#!c (gdb) print (StgInfoTable)(*(obj->header.info - 1)) $50 = {layout = {payload = {ptrs = 0, nptrs = 0}, bitmap = 0, large_bitmap_offset = 0, __pad_large_bitmap_offset = 0, selector_offset = 0}, type = 14, srt_bitmap = 0, code = 0x405268e8 "I\203\304\030M;\245X\003"} }}} `type = 14` corresponds to: {{{#!c #define FUN_STATIC 14 }}} . Therefore no need to evaluate anything (the switch just `break`s for this case). We then move [https://github.com/ghc/ghc/blob/cca2d6b78f97bfb79bef4dc3f75d6c4d15b94680/rts... here]. {{{#!c // ------------------------------------------------------------------------ // We now have an evaluated object (tagged_obj). The next thing to // do is return it to the stack frame on top of the stack. do_return: obj = UNTAG_CLOSURE(tagged_obj); ASSERT(closure_HNF(obj)); /* ... */ switch (get_itbl((StgClosure *)Sp)->type) { }}} In our case: {{{#!c (gdb) print (StgInfoTable)(*(c->header.info - 1)) $49 = {layout = {payload = {ptrs = 2, nptrs = 0}, bitmap = 2, large_bitmap_offset = 2, __pad_large_bitmap_offset = 2, selector_offset = 2}, type = 30, srt_bitmap = 0, code = 0x2cfa6a0 "\200<%Rw<\003"} }}} So `type = 30`, which is: {{{#!c #define RET_SMALL 30 }}} which makes us hit the `RET_SMALL` case. {{{#!c case RET_SMALL: { const StgInfoTable *info; // NOTE: not using get_itbl(). info = ((StgClosure *)Sp)->header.info; if (info == (StgInfoTable *)&stg_restore_cccs_info || info == (StgInfoTable *)&stg_restore_cccs_eval_info) { cap->r.rCCCS = (CostCentreStack*)SpW(1); Sp_addW(2); goto do_return; } if (info == (StgInfoTable *)&stg_ap_v_info) { n = 1; m = 0; goto do_apply; } if (info == (StgInfoTable *)&stg_ap_f_info) { n = 1; m = 1; goto do_apply; } if (info == (StgInfoTable *)&stg_ap_d_info) { n = 1; m = sizeofW(StgDouble); goto do_apply; } if (info == (StgInfoTable *)&stg_ap_l_info) { n = 1; m = sizeofW(StgInt64); goto do_apply; } if (info == (StgInfoTable *)&stg_ap_n_info) { n = 1; m = 1; goto do_apply; } if (info == (StgInfoTable *)&stg_ap_p_info) { n = 1; m = 1; goto do_apply; } if (info == (StgInfoTable *)&stg_ap_pp_info) { n = 2; m = 2; goto do_apply; } if (info == (StgInfoTable *)&stg_ap_ppp_info) { n = 3; m = 3; goto do_apply; } if (info == (StgInfoTable *)&stg_ap_pppp_info) { n = 4; m = 4; goto do_apply; } if (info == (StgInfoTable *)&stg_ap_ppppp_info) { n = 5; m = 5; goto do_apply; } if (info == (StgInfoTable *)&stg_ap_pppppp_info) { n = 6; m = 6; goto do_apply; } goto do_return_unrecognised; } }}} We take the `info == (StgInfoTable *)&stg_ap_pp_info` branch and head to `do_apply` [https://github.com/ghc/ghc/blob/cca2d6b78f97bfb79bef4dc3f75d6c4d15b94680/rts... here]. There we just hit the default branch: {{{#!c default: defer_apply_to_sched: IF_DEBUG(interpreter, debugBelch("Cannot apply compiled function; yielding to scheduler\n")); Sp_subW(2); SpW(1) = (W_)tagged_obj; SpW(0) = (W_)&stg_enter_info; RETURN_TO_SCHEDULER_NO_PAUSE(ThreadRunGHC, ThreadYielding); /* where: */ #define SAVE_STACK_POINTERS \ cap->r.rCurrentTSO->stackobj->sp = Sp; #define SAVE_THREAD_STATE() \ SAVE_STACK_POINTERS #endif #define RETURN_TO_SCHEDULER_NO_PAUSE(todo,retcode) \ SAVE_THREAD_STATE(); \ cap->r.rCurrentTSO->what_next = (todo); \ cap->r.rRet = (retcode); \ return cap; }}} FWIW, right before we return to the scheduler, the stack looks like: {{{#!c (gdb) x/8a Sp 0x42001fcb10: 0x2cf5900 0x407c6c20 0x42001fcb20: 0x2cfa6a0 0x407a0540 0x42001fcb30: 0x401618a8 0x2cf34e8 0x42001fcb40: 0x42003b2eb0 0x10202e0 }}} But then, when I continue executing the program instruction by instruction, gdb shows me {{{#!c default: barf("interpretBCO: unknown or unimplemented opcode %d", (int)(bci & 0xFF)); }}} which is the default case for the switch on the opcode we read from a BCO. Not sure what's going on here, because there's just no way the control flow leads us there. So I quickly tried another run, but setting a breakpoint on `barf`, and we just never call it. This suggests that `interpretBCO` in fact goes well and that it does set things up properly on the stack and saves the stack in the capability's state. And `gdb` just points me to `default` for lack of a better line, when it is executing the function, I suppose? Next I'll look at what goes on when `convertAnnotationWrapper` picks this up. By quickly skimming through it in `gdb` I see some allocations, some `Data.Data` related symbol (comes from `AnnotationWrapper`'s constructor IIRC), some pinned byte array related ones as well. Hopefully this step will reveal the actual problem... -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14675#comment:16 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#14675: GHC 8.4.1 regression: segfault when loading doctest on a module with ANNs on Ubuntu 16.04 or later -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: GHC API | Version: 8.4.1-alpha1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #14603 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * owner: alpmestan => bgamari Comment: Handing this off to Ben as I have not (yet) been able to create a virtual machine that provides the hardware performance counters needed by `rr`, which really is the only sane way to figure out how we end up jumping to an invalid address. Off to you, Ben. :) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14675#comment:18 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#14675: GHC 8.4.1 regression: segfault when loading doctest on a module with ANNs on Ubuntu 16.04 or later -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: GHC API | Version: 8.4.1-alpha1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #14603 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I have done a bit of characterisation of the issue since I fear we simply don't have time at this point to come up with a proper solution for 17.10. ||= Distribution =||= binutils version =||= glibc version =||= Affected =|| || Ubuntu Wily (15.10) || || || || || Ubuntu Xenial (16.04) || 2.26 || 2.23 || Yes || || Ubuntu Zesty (17.04) || 2.28 || 2.24 || No || || Debian Jessie (9.0) || 2.28 || 2.24 || No || || Ubuntu Artful (17.10) || 2.29 || 2.26 || No || -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14675#comment:20 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#14675: GHC 8.4.1 regression: segfault when loading doctest on a module with ANNs on Ubuntu 16.04 or later -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: GHC API | Version: 8.4.1-alpha1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #14603 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Ok, I think I have a bit more info on this, and a better workaround. For me the crash happened here: {{{ (gdb) disassemble 0x0000000040792900,0x0000000040792910 Dump of assembler code from 0x40792900 to 0x40792910: 0x0000000040792900: mov 0x10(%rbp),%rax 0x0000000040792904: mov %rbx,%rcx 0x0000000040792907: and $0x7,%ecx => 0x000000004079290a: jmpq *0x403ff568(,%rcx,8) }}} and the memory at 0x403ff568 looks bogus. By using `+RTS -Dl` and digging through the logs, correlating this with `objdump --reloc HSbase-4.11.0.0.o`, I got that this relocation is: {{{ 00000000004228cd R_X86_64_32S .rodata-0x0000000000451cd8 }}} which is utterly bogus: we should never have a negative offset into a section. The original object file, before it was squashed into `HSbase-4.11.0.0.o` has this: {{{ 0000000000000b3d R_X86_64_32S .rodata..LneLq }}} which is a sensible relocation to the unique section name `.rodata..LneLq`. Looks like something has gone wrong when we squashed the object files together to make `HSBase-4.11.0.0.o`. Indeed, if I take the command line to squash the object files and replace `ld.gold` with `ld`, then I get this relocation: {{{ 00000000004228cd R_X86_64_32S .rodata+0x000000000000e158 }}} which is much more sensible. And after doing that, the crashing program now works. So this suggests that the workaround should be to avoid using `ld.gold` for squashing objects together, I'll make a diff. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14675#comment:22 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#14675: GHC 8.4.1 regression: segfault when loading doctest on a module with ANNs on Ubuntu 16.04 or later -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: GHC API | Version: 8.4.1-alpha1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #14603 | Differential Rev(s): Phab:D4431 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * differential: => Phab:D4431 * blockedby: 14328 => -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14675#comment:25 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#14675: GHC 8.4.1 regression: segfault when loading doctest on a module with ANNs on Ubuntu 16.04 or later -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: GHC API | Version: 8.4.1-alpha1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #14603 | Differential Rev(s): Phab:D4431 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Marlow ): In [changeset:"0a3629af36e89de73b7012c726fd533c4c5460fb/ghc" 0a3629af/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0a3629af36e89de73b7012c726fd533c4c5460fb" Don't use ld.gold when building libraries for GHCi Summary: ld.gold is buggy when using -r and a linker script. See upstream bug https://sourceware.org/bugzilla/show_bug.cgi?id=22266 This has been causing various brokenness for the GHC runtime linker, where we load these broken object files. Test Plan: Test program from #14675 Reviewers: bgamari, RyanGlScott, alpmestan, hvr, erikd Subscribers: rwbarton, thomie, erikd, carter GHC Trac Issues: #14328, #14675, #14291 Differential Revision: https://phabricator.haskell.org/D4431 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14675#comment:27 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#14675: GHC 8.4.1 regression: segfault when loading doctest on a module with ANNs on Ubuntu 16.04 or later -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: closed Priority: highest | Milestone: 8.4.1 Component: GHC API | Version: 8.4.1-alpha1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #14603 | Differential Rev(s): Phab:D4431 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged with b4e32780a976193208eebbddf789eeb80351ac95. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14675#comment:29 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler