[
https://issues.apache.org/jira/browse/BCEL-190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jérôme Leroux updated BCEL-190:
-------------------------------
Attachment: BCEL-190.patch
Attach patch with:
* Partial Fix for BCEL-190
* Test for BCEL-190
The fix consists in ignoring the assignement compatibility checks when the
expected type is an interface. The verifier may not reject some invalid
classfiles with this fix.
This kind of _workaround_ is comparable to the implementation done in the
Oracle JVM but it is not complete. The Oracle JVM does some additional tests at
runtime when executing the opcode when interfaces are involved.
See §16.1.2 of _Robert F. Stärk, Joachim Schmid, and Egon Börger. Java and
the Java Virtual Machine – Definition, Verification, Validation.
Springer–Verlag, 2001_
{quote}
Sun’s JDK 1.2 verifier does not reject the bytecode. Instead it inserts
an additional run-time check for methods with arguments of interface type.
Hence, the compatibility of method arguments has to be checked at run-
time in contradiction to the JVM specification.
{quote}
A complete fix may use the _sets of reference types_ as described by _Stärk_ in
the same chapter.
> Type inference computing not correct in bytecode verifier
> ---------------------------------------------------------
>
> Key: BCEL-190
> URL: https://issues.apache.org/jira/browse/BCEL-190
> Project: Commons BCEL
> Issue Type: Bug
> Components: Verifier
> Affects Versions: 6.0
> Reporter: Jérôme Leroux
> Attachments: BCEL-190.patch
>
>
> As described in the verifier documentation, there are some known issues in
> the variable type inference computing.
> {quote}
> JustIce uses object generalization during pass 3b, as supposed by
> Sun. However, there are better methods such as the idea proposed by
> Staerk et al.: using sets of object types. JustIce may reject code
> that is not rejected by traditional JVM-internal verifiers for this
> reason. The corresponding checks all have some "TODO" tag with an
> explanation; they're all in the 'Pass3bVerifier' files.
> Users encountering problems should simply comment them out (or
> uncomment them) as they like.
> {quote}
> Here is a simple example that reproduces this issue. It is rejected by the
> verifier:
> {code:java}
> public void test1(boolean b) throws IOException {
> Appendable s;
> if(b) {
> s = System.out;
> }
> else {
> s = new StringBuilder();
> }
> test2(s);
> }
>
> public void test2(Appendable s){}
> {code}
> To avoid this example to be rejected by the verifier, it should be more
> tolerant. This may lead to accept some invalid bytecode but IMHO it is
> preferable. Actually there are already some bugs that accept invalid
> bytecode, especially in invokeinterface analyze.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
