[GHC] #14675: GHC 8.4.1 regression: segfault when loading doctest on a module with ANNs on Ubuntu 16.04 or later

[GHC]

#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