Closed eriksoe closed 14 years ago
Appears to be related to beam-level knowledge that erlang:error() never returns. The compiler omits "try_end" in the beam code, for example; "try_end" is present if some other function is called instead: {'try',{y,1},{f,6}}. {'try',{y,0},{f,3}}. {move,{atom,x},{x,0}}.
Oops - wrong button. How to reopen?
Yeo. There's some logic in the codegen for call_ext calling isTerminal or something and then injects a return insn in that case. Perhaps erlang:error/1 is missing there.
Yes - I remember introducing it, but failed to quickly locate it when searching for 'error' - no wonder then. I'll try to fix.
isTerminal is gone, apparently - I think the issue is that only tail calls has this special treatment at present.
This appears to be a kilim issue; the 'dup' in question is the first instruction in an exception handler block - where the stack isn't empty. FTR, the input to kilim passes jvmverifier.
Verified: It's not a beam verification issue at all; it is a kilim shortcoming. Kilim patch written, tested and sent to the maintainer.
The code: exn() -> try erlang:error(x) catch E -> {caught,E} after io:format("after\n") end.
results in this error: l(exntest). 13-11-2010 10:36:10 erjang.m.erlang.ErlBif load_module SEVERE: cannot load module exntest java.lang.RuntimeException: Verify error. Expected word in stack, but stack is empty at kilim.analysis.Frame.pop(Frame.java:231) at kilim.analysis.Frame.popWord(Frame.java:236) at kilim.analysis.BasicBlock.interpret(BasicBlock.java:613) at kilim.analysis.MethodFlow.dataFlow(MethodFlow.java:374) at kilim.analysis.MethodFlow.analyze(MethodFlow.java:126) at kilim.analysis.ClassFlow.analyze(ClassFlow.java:104) at kilim.analysis.ClassWeaver.weave(ClassWeaver.java:59) at kilim.analysis.ClassWeaver.(ClassWeaver.java:45)
at erjang.beam.Compiler.compile(Compiler.java:104)