RFR: 8049632: JDK 1.8.0 b132 :Linux x64 : Crash in ClassFileParser::copy_localvariable_table(..)

[Coleen Phillimore]

On 1/28/15, 7:33 PM, serguei.spitsyn at oracle.com wrote:
> Coleen,
>
> The fix looks good.
> It is great, you added new tests for it, thanks!

Thank you for the code review, Serguei!

>
> I have one question about the tests though.
> It seems there are no duplicated LVT/LVTT in the tests *DuplicateLVT.cod,
> **DuplicateLVTT.cod* and *NotFoundLVTT.cod* has LVTT.

In DuplicateLVT.cod, the LVT entry starting with '5' was duplicated.

             Attr(#39) { // LocalVariableTable
               [] { // LocalVariableTable
                 0 279 44 45 0;
                 2 277 46 47 1;
                 5 274 48 49 2;
                 5 274 48 49 2;
                 8 271 50 51 3;
                 13 266 52 53 4;
                 17 262 54 55 6;
                 21 258 56 57 7;
                 26 253 58 59 8;
                 30 249 60 61 10;
                 39 240 62 63 11;
               }

DuplicateLVTT.cod has:

             Attr(#64) { // LocalVariableTypeTable
               [] { // LocalVariableTypeTable
                 39 240 62 65 11;
                 39 240 62 65 11;
               }

NotFoundLVTT.cod is more interesting because it has to refer to LVT, so 
I changed the entry from 39 to 38:

             Attr(#64) { // LocalVariableTypeTable
               [] { // LocalVariableTypeTable
                 38 240 62 65 11;
               }

Thanks,
Coleen

>
> Do I miss anything?
>
> Thanks,
> Serguei
>
>
> On 1/28/15 8:11 AM, Coleen Phillimore wrote:
>> Summary: Use resource allocated hashtable for local variable table 
>> checking
>>
>> I was never able to reproduce this after considerable time trying. I 
>> also never found anything wrong with the code that would cause an 
>> extra or incorrect os::free call.  This change checks LVT entries 
>> using the existing ResourceHashtable rather than a ad-hoc extra 
>> hashtable definition in classFileParser.cpp.  So this change removes 
>> the os::free call. I think whatever caused the original bug will 
>> crash somewhere else now, and hopefully be easier to find.
>>
>> Tested with jck9, jck1.4 runThese tests, nsk and jtreg tests, and 
>> added test.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8049632/
>> bug link https://bugs.openjdk.java.net/browse/JDK-8049632
>>
>> Thanks,
>> Coleen
>>
>