Java class file verification

[John Bergin]

Hi again, Alex. Many thanks for your response. It makes a lot of sense
to me. I guess the implementation of the Java Virtual Machine
specification isn't entirely upheld with regard to attributes. In fact
your note on Runtime*Annotations makes a lot of sense too since I have
a class containing a RuntimeVisibleAnnotation whose
attribute_name_index references a CONSTANT_String_info instead of a
CONSTANT_Utf8_info and this class passes verification at load-time but
once the annotation is reflected an exception is thrown.

Anyway, I'll move this discussion to a bug. Thanks again.

Kind regards,
John.



Date: Wed, 14 Jan 2015 13:02:03 -0800
From: Alex Buckley <alex.buckley at oracle.com>
To: discuss at openjdk.java.net
Subject: Re: Java class file verification
Message-ID: <54B6D94B.7080708 at oracle.com>
Content-Type: text/plain; charset=UTF-8; format=flowed

Hi John,

Per
http://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.7,
LocalVariableTable is not critical to correct interpretation of the
class file by the JVM, so a JVM implementation like HotSpot is permitted
to leave constraint checking up to the libraries. (This happens with the
Runtime*Annotations attributes, for example.)

That said, I believe HotSpot in JDK 8 does go to the trouble of throwing
ClassFormatError for oddball LocalVariableTable attributes:

     LocalVariableTable - Throws CFE if:
         start_pc >= code_length
         start_pc + length > code_length
         name_index or descriptor_index is invalid
         the name at name_index is not a legal field name
         the signature at descriptor_index is not a legal field signature
         index is a valid index in the local variable array

Probably best if you file a HotSpot bug on bugs.java.com so we can
diagnose details there, not on a general discuss list.

Alex

On 1/14/2015 12:35 PM, John Bergin wrote:
> Hi all.
> 
> I have a query regarding Java class file verification in
> particular verification of the LocalVariableTable attribute defined
> by the Java Virtual Machine 7 specification here,
> 
> 
http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html#jvms-4.7.13
> 
> The specification states that "The value of start_pc must be a
> valid index into the code array of this Code attribute and must be
> the index of the opcode of an instruction." And in the example
> below the start_pc for args is 0 and for s it is 3 and both these
> indexes are valid code array offsets.
> 
> public static void main(java.lang.String[]); flags: ACC_PUBLIC,
> ACC_STATIC Code: stack=1, locals=2, args_size=1 0: ldc           #2
> // String A string 2: astore_1 3: return LineNumberTable: line 3:
> 0 line 4: 3 LocalVariableTable: Start  Length  Slot  Name
> Signature 0       4     0  args   [Ljava/lang/String; 3       1
> 1     s   Ljava/lang/String;
> 
> My question is: a program I'm helping to develop is dynamically 
> generating Java class files where the start_pc indexes are NOT
> valid indexes into the code array (in fact they're off by one) and
> OpenJDK is not rejecting the class via a ClassFormatException. Has
> anyone got any idea why this is the case?
> 
> Kind regards, John.
>