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