#14736: unknown opcode in interpretBCO doesn't cause process termination in some circumstances ----------------------------------------+--------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1-alpha1 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- As part of my work on #14675, I ended up in a situation where `rts/Interpreter.c:interpretBCO` falls into its default case, which just does this: {{{#!c barf("interpretBCO: unknown or unimplemented opcode %d", (int)(bci & 0xFF)); }}} Which is fine. In the program from #14675, we are not processing the annotations with an external interpreter, the same runtime is compiling some module and running some code for the annotations, if my understanding is correct. And that process should therefore terminate. Except that it doesn't, not right away! And the example that uses the GHC API to load some simple module with an annotation just happily proceeds until it segfaults because `interpretBCO` didn't run to completion, probably therefore not pushing a suitable closure address or two somewhere or something along those lines. The expected behaviour here would be that the program crashes with the "unknown opcode" error message from above. So far the problem from #14675 has only been reproduced on ubuntu 16.04 with 8.4.1 alpha1, however I suspect that the bug I'm describing -- the program not terminating when we call `barf` while running code that we will splice in some module that we are compiling using the GHC API -- is independent of the particular distro or maybe even OS? Not sure, I haven't looked into that. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14736 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler