Java class file verification
john.bergin at gmail.com
Wed Jan 14 23:00:47 UTC 2015
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.
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
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.
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,
> 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.
More information about the discuss