RFR (s) 8148772: VM crash in nsk/jvmti/RedefineClasses/StressRedefine: assert failed: Corrupted constant pool

Coleen Phillimore coleen.phillimore at oracle.com
Sat Apr 9 13:02:43 UTC 2016



On 4/8/16 5:20 PM, Christian Thalinger wrote:
>
>> On Apr 8, 2016, at 11:06 AM, Coleen Phillimore 
>> <coleen.phillimore at oracle.com <mailto:coleen.phillimore at oracle.com>> 
>> wrote:
>>
>> Summary: ConstantPool::resolve_constant_at_impl() isn't thread safe 
>> for MethodHandleInError and MethodTypeInError.
>>
>> Need to ignore the InError tag when fetching method_handle_index and 
>> method_type_index.  The error is cached after the call to 
>> systemDictionary::link_method_handle_constant() if it's not there 
>> already.
>>
>> Tested with rbt equivalent of nightly runs, and StressRedefine test 
>> (reproduceable with this error) for >24 hours (also with 8151546 
>> fixed).  Ran jdk/test/java/lang/invoke tests.  I can't write a test 
>> for this because it's too timing sensitive.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8148772.01/webrev 
>> <http://cr.openjdk.java.net/%7Ecoleenp/8148772.01/webrev>
>
>     default:
> + DEBUG_ONLY( tty->print_cr("*** %p: tag at CP[%d] = %d",
> + this, index1, t1));
> + assert(false, "unexpected constant tag");
> +
>       ShouldNotReachHere();
>       break;
>     }
> Merge the print_cr and assert into a fatal and remove 
> the ShouldNotReachHere.

That was mistakenly left in debugging some other bug.  I reverted this 
change.

Thanks,
Coleen
>
>> bug link https://bugs.openjdk.java.net/browse/JDK-8148772
>>
>> Thanks,
>> Coleen
>>
>>
>>
>>
>>
>



More information about the hotspot-dev mailing list