#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 made some more progress on this. It turns out that when not using an external interpreter -- like in the program from this ticket -- we run/evaluate annotations with the same runtime system that runs the program. I set a breakpoint on the evaluation of the `unsafeCoerce# ...` expression and tried to follow the execution along in gdb and in the source code of the RTS. I first saw some `Data.Data` related symbol/closure and was the led into the scheduler to later land in `rts/Interpreter.c:interpretBCO`. That function successfully interprets a few opcodes but at some point the `switch` takes the `default` branch: {{{#!c default: barf("interpretBCO: unknown or unimplemented opcode %d", (int)(bci & 0xFF)); }}} with `bci & 0xFF` equal to 32. In other words, the bytecode object interpreter gives up and we would expect the program to crash at that point, with the given error message. Except that it looks like even if we're not using an external interpreter, this does _not_ shut down the runtime system. Instead, the RTS happily goes back to compiling our module, as if the BCO interpreter had completed successfully. This unsurprisingly causes a problem just further down the road, when we're actually trying to read the result of the BCO interpreter as a Haskell value of type `AnnotationWrapper`. I have documented this unexpected behaviour in #14736, but this is not the end of the story as far as this ticket is concerned. Also, Ben pointed out to me that: {{{#!c #define bci_PUSH_APPLY_PP 32 }}} So it looks to me like we _should_ be able handle that opcode... Anyway, now that I know a lot more about what's going on, I'll set some more interesting breakpoints tomorrow, e.g on `interpretBCO`, and try to trace exactly what the interpreter reads. Similarly, I would like to see if I can pinpoint where exactly we "produce" the input to the interpreter (that we `unsafeCoerce#` to an `AnnotationWrapper`). I should eventually converge on the problem. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14675#comment:15 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler