RFR(S) 8137314: vm crash from test java/security/Policy/SignedJar/SignedJarTest.java

harold seigel harold.seigel at oracle.com
Fri Jan 15 14:53:47 UTC 2016


Hi Karen,

Thanks for reviewing this so quickly.

Harold

On 1/15/2016 9:41 AM, Karen Kinnear wrote:
> Harold,
>
> Change looks good. Thank you for doing this in jdk9 since it is a general issue.
> And thank you both for the extensive testing and for listing it in the RFR :-)
>
> thanks,
> Karen
>
>> On Jan 14, 2016, at 4:00 PM, harold seigel <harold.seigel at oracle.com> wrote:
>>
>> Hi,
>>
>> Please review this small change to fix bug 8137314 <https://bugs.openjdk.java.net/browse/JDK-8137314>
>>
>> The bug is that the JVM verifier asserts when it is called recursively to verify a class that has already been linked.  There already exist checks in the verifier to prevent recursive verification of a class.  This fix adds additional checks including one needed to prevent the JVM assert.
>>
>> The additional checks were added wherever there was a constant pool reference following a call that could potentially load a class. Loading a class causes the JVM to call back to the JDK to do a protection domain check which can then cause classes to get linked and executed.  And, linking changes a class's constant pool.  There are many places in the verifier that could load a class because is_assignable_from() may load a class.  But, most of them encounter an existing recursive verification check before accessing the constant pool.  These checks already exist after every verify_method() call and after every bytecode is verified.
>>
>> Although the problem occurred in the Jake repo, it's being fixed in JDK-9 because the problem is not Jigsaw specific.
>>
>> Open webrev: http://cr.openjdk.java.net/~hseigel/bug_8137314/
>>
>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8137314
>>
>> The fix was tested with JCK Lang and VM tests, UTE quick and split verifier tests, and the hotspot, JDK vm, java/io, java/lang, and java/util JTreg tests, and the test case reported  in this RFR.
>>
>> Thanks, Harold



More information about the hotspot-runtime-dev mailing list