CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
mantis

FIXED IN:
mantis

INTEGRATED IN:
mantis
mantis-b07


                                     

PUBLIC COMMENTS

We expect to modify the verifier spec and implementation by JDK 1.5 so that 
this will not be an issue.
                                     

EVALUATION

Looks like a verifier issue.

Both javac and oldjavac produce the same code for this example, which
appears to be correct.  Note that the code does attempt to subscript
an array variable that contains null, which should result in an
exception at runtime.  The generated code is as follows:

super public class ArrayTest
{


public Method "<init>":"()V"
	stack 1 locals 1
{
		aload_0;
		invokespecial	Method java/lang/Object."<init>":"()V";
		return;
}

public static Method main:"([Ljava/lang/String;)V"
	stack 0 locals 1
{
		return;
}

private static Method neverCalled:"()V"
	stack 4 locals 1
{
		aconst_null;
		astore_0;
		aload_0;
		iconst_0;
		aload_0;
		iconst_0;
		aaload;
		invokestatic	Method resize:"([F)[F";
		aastore;
		return;
}

private static Method resize:"([F)[F"
	stack 1 locals 1
{
		aconst_null;
		areturn;
}

} // end Class ArrayTest


william.maddox@Eng 2000-10-24

=======================================================

This is not a verifier bug. The byte code in method neverCalled() as shown above has a type error in aastore.  

The compiled byte code has lost the declaration information in the source code.
Therefore local variable 0 does not has [[F type. Instead, both local variable 0 and its value pushed on operand stack have null type. Their component types are null as well.

After method 'resize' is invoked, the verifier pushes type [F (return type of 'resize') on the operand stack. Note that each method is verified separately. So method 'neverCalled' does not know that 'resize' returns null. It only knows that 'resize' returns [F from its signature. 

According to JVM Spec 2nd edition P. 176 (aastore), the top of current operand stack type (the return type of 'resize') must be assignment compatible with the type of the components of the array type on the third of operand stack (it is null here). Because type [F is not assignable to null, the verifier detects a type error. 

Another workaround is to assign resize(channels[0]) to another variable instead of channels[0], or directly assign null to channels[0] without calling resize.

This bug will be closed as not a bug.

###@###.###    2001-7-10

I'm reopening this report, because our toolchain still doesn't function.
Yes, the verifier is behaving as specified, but nevertheless a correct
Java program fails to run.

This is an unfortunate mismatch between the compikler (javac) and the
verifier.  I'm keeping this bug open until the program runs fine
on the product.

Note that it would be possible to "fix" the compiler by emitting casts into
the code whenever null is used as a value of a multidimensional array type.

###@###.### 2002-09-26
                                     

WORK AROUND



Name: tb29552			Date: 09/06/2000


Do not use "float[][] x=null". Use "float[][] x=new float[0][]" instead.
======================================================================

An alternative workaround:

Do not use "channels[0] = resize(channels[0]);". 
Use "float[] temp = resize(channels[0]);" or "channels[0] = null;" instead.

###@###.###    2001-7-10