commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jérôme Leroux (JIRA) <>
Subject [jira] [Updated] (BCEL-190) Type inference computing not correct in bytecode verifier
Date Thu, 08 Jan 2015 16:27:34 GMT


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_
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.

A complete fix may use the _sets of reference types_ as described by _Stärk_ in the same

> Type inference computing not correct in bytecode verifier
> ---------------------------------------------------------
>                 Key: BCEL-190
>                 URL:
>             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

View raw message