Summary: | [compiler] Possible wrong bytecode generated for nested try-finally blocks: ret is part of more than one subroutine | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Nina Rinskaya <nina.rinskaya> |
Component: | Core | Assignee: | Olivier Thomann <Olivier_Thomann> |
Status: | VERIFIED INVALID | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | alexei.fedotov, philippe_mulet |
Version: | 3.3 | ||
Target Milestone: | 3.4 M1 | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: |
Description
Nina Rinskaya
2007-06-26 07:16:27 EDT
Here is a trackback URL: http://issues.apache.org/jira/browse/HARMONY-3862 A workaround is to use the option to inline jsrs. Same bug is found in old 1.4 javac version (1.4.0_04). Latest versions of javac 1.4.2 are inlining the inner finally blocks. So they never end up with a shared ret bytecodes. Using the option -XDjsrlimit=0 with latest jdk1.4.2 produces a .class file that leads to the same error. I think the problem comes from the exception handlers. In theory, the line [20 52 52 Class java/lang/Exception] means that it is possible to escape from nested finally back into outer one; which must cause grief to bytecode verifier. Need to check code generation, which is supposed to properly exit/reenter code blocks as appropriate (and this would indicate the bug if not doing it properly). I believe it should generate a sub interval for the nested finally block. Actually, the exception handler is correct, to ensure the proper control transfer if an exception occurs at pc 41. Could it be that the spec is being too strict ? And the reason why Sun's verifier doesn't enforce the extra constraint ? It seems that it is legal to return to a higher level in the subroutines call chain. From the JVMS (2nd edition): http://java.sun.com/docs/books/jvms/second_edition/html/ClassFile.doc.html#9308 "Each instance of type returnAddress can be returned to at most once. If a ret instruction returns to a point in the subroutine call chain above the ret instruction corresponding to a given instance of type returnAddress, then that instance can never be used as a return address." This would mean that as long as the ret instruction is executed only once, this is fined. It would be a verify error if the ret 3 could be executed after the ret 1 has been executed. So I would close this one as WONTFIX since the code generation is actually fine and it seems that the Harmony bytecode verifier is too strict. Philippe, any comment on this ? Makes sense, otherwise, I don't see how we could generate proper bytecode meeting runtime expectation (other than by inlining some subroutines, but this would feel a bit of a hack). I'd like to hear back from Harmony verifier... Then we should close as INVALID. I am waiting from an update coming from the Harmony team. Closing as INVALID. Thanks, Philippe and Olivier, for an excellent citation. It seems the following is true: a subroutine may conditionally branch to the code which is part of an upper level subroutine. Verified by reporter |