Bug 26839 - JustIce - array store type checks stricter than native verifier
Summary: JustIce - array store type checks stricter than native verifier
Status: ASSIGNED
Alias: None
Product: BCEL - Now in Jira
Classification: Unclassified
Component: Main (show other bugs)
Version: unspecified
Hardware: All All
: P3 normal
Target Milestone: ---
Assignee: issues@commons.apache.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-02-10 19:56 UTC by Peter Taylor
Modified: 2006-03-01 19:25 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Taylor 2004-02-10 19:56:15 UTC
Consider the class

public class Demo
{
    public static void main(String[] args)
    {
        Object[] objs = new Integer[1];
        objs[0] = o();
    }

    private static Object o()
    {
        return null;
    }
}

It compiles fine, and
java -verify Demo
executes without errors. However,
java org.apache.bcel.verifier.Verifier Demo
complains:

Pass 3b, method number 1 ['public static void main(String[] arg0)']:
VERIFIED_REJECTED
Constraint violated in method 'public static void main(String[] arg0)':
Instruction AASTORE constraint violated: The type of 'value' ('java.lang.Object') is not assignment 
compatible to the components of the array 'arrayref' refers to. ('java.lang.Integer')
etc.

The problem is that while the vmspec2 says "The type of every value stored into an array of type 
reference by an aastore instruction must be assignment compatible (ยง2.6.7) with the component 
type of the array", the class file doesn't contain information on the compile-time component type 
of the array. I suspect the native verifier does nothing about this requirement, leaving the VM to 
throw an ArrayStoreException if problems arise.

Enver Haase asked me to mention in this report that while the error message says "assignment 
compatible to" and the vmspec2 says "assignment compatible with", it's not a case of doing the 
check the wrong way round.
Comment 1 Stephen Cheng 2004-02-10 21:29:51 UTC
Here is my understanding of the problem:
1. Verification type of objs is Object[]
2. Run-time type of objs (in this particular case) is Integer[]
3. Verification type of the result of o() is Object

Verification should pass, since it is purely concerned about verification 
type. However a run-time error should be thrown if o() return a non-null 
value. In this case since o() return null it shouldn't.

scheng@innaworks.com
Comment 2 Peter Taylor 2004-02-11 16:38:33 UTC
Not quite. A run-time error should be thrown if o() return a non-null value which is not an Integer.