Request for review: JDK-8011260: fatal error: LineNumberTable attribute has wrong length in class file

harold seigel harold.seigel at oracle.com
Wed Apr 10 07:27:33 PDT 2013


Hi David,

Thanks for looking at this.  To clarify, by "anonymous classes" I mean 
only classes loaded by the anonymous class loader, not anonymous inner 
classes.

Please see in-lined responses.

Thanks, Harold

On 4/9/2013 8:03 PM, David Holmes wrote:
> Hi Harold,
>
> On 9/04/2013 11:55 PM, harold seigel wrote:
>> Hi,
>>
>> Please review the following bug fix:
>>
>> Summary:   The assertion was prevented by changing the code to verify
>> classes loaded by the anonymous class loader, unless -noverify was
>
> So if I understand this right:
>
> - previously: loader == NULL -> BytecodeVerificationLocal
> - now: loader == NULL && anonymous-loader ->
> BytecodeVerificationRemote
>
> in other words we were skipping verification for anonymous classes.
Yes, unless full verification (-verify) was explicitly specified or 
their host classes had their own non-null class loaders.
>
> I guess I don't fully understand the implications here. Given we 
> normally skip verification for classes loaded by the boot-loader, does 
> this mean we now verify anonymous classes "linked" to the boot-loader? 
> Are all anonymous classes considered to be non-boot-loader classes?
>
Yes, we would now verify anonymous classes "linked" to the boot-loader.

The answer to 'should anonymous calls considered to be non-boot-loader 
classes" might be yes and no, depending on the context.  And this change 
proposes that the answer be 'no' when it comes to whether or not to skip 
verification.

> Makes me wonder if there are other places where we check a loader for 
> NULL but also need to check it is not related to anonymous classes ?
>
That's a good point.  Should I create a new bug to look into this?
>> specified.  Also, the relevant assertion messages were improved to
>> include additional information, including class name.
>
> Thanks for that. I hadn't realized the classfile_parse_error routines 
> created and threw exceptions.
>
> David
> -----
>
>> Open webrev at http://cr.openjdk.java.net/~hseigel/bug_8011260/
>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8011260/>
>>
>> Bug link at http://bugs.sun.com/view_bug.do?bug_id=8011260
>>
>> The change was tested by hand to ensure that the assertion no longer
>> occurs when the test is run.  Additional testing was done using JCK Lang
>> and VM, JTREG tests, ute vm.quick.testlist and vm.mlvm.testlist tests,
>> and JPRT tests.
>>
>> Thank you!
>> Harold



More information about the hotspot-runtime-dev mailing list