unknown opcode in interpretBCO doesn't cause process termination in some circumstances
As part of my work on #14675 (closed), I ended up in a situation where rts/Interpreter.c:interpretBCO
falls into its default case, which just does this:
barf("interpretBCO: unknown or unimplemented opcode %d",
(int)(bci & 0xFF));
Which is fine. In the program from #14675 (closed), 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 (closed) 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.
Trac metadata
Trac field | Value |
---|---|
Version | 8.4.1-alpha1 |
Type | Bug |
TypeOfFailure | OtherFailure |
Priority | normal |
Resolution | Unresolved |
Component | Compiler |
Test case | |
Differential revisions | |
BlockedBy | |
Related | |
Blocking | |
CC | |
Operating system | |
Architecture |