RFR (S) 7127066: Class verifier accepts an invalid class file

[Keith McGuigan]

Hi Harold,

Thanks for the background.  The code does look good to me given that
explanation.  In the future if we can keep JIRA records "open" as much as
possible it will make future open collaboration easier.


On Fri, Aug 29, 2014 at 8:41 AM, harold seigel <harold.seigel at oracle.com>
wrote:

> Hi,
>
> Resending this RFR with a description of the bug because the bug is not
> accessible to all reviewers.
>
> The bug is that the verifier accepts a class that it should not.
> Verification should fail because, in this case, the stack map at a TRY
> block's astore_2 instruction does have enough locals to satisfy the stack
> map for one of its covering exception handlers.  However, the HotSpot VM
> class verifier does not detect the problem, and loads the class.
>
> The root cause of this issue is that the verifier is using the result type
> state from the astore_2 instruction, instead of correctly using the
> incoming type state, when checking for a compatible type-state for the
> exception handler. This is not-to-spec, as JVMS 8 does indicate that the
> instruction's incoming type state (with expression stack modification)
> should be used for type checking the covering exception handlers.
>
> I hope this compensates for the inaccessibility of the bug.
>
> Thanks, Harold
>
>
> On 8/28/2014 5:07 PM, harold seigel wrote:
>
>> Hi,
>>
>> Please review this small verifier fix for bug JDK-7127066.  The change
>> fixes the problem by doing the exception handler type state verification
>> for byetcodes, such as astore, that modify the type state, before the type
>> state gets modified.
>>
>> bug:  https://bugs.openjdk.java.net/browse/JDK-7127066
>> Open webrev: http://cr.openjdk.java.net/~hseigel/bug_7127066/
>>
>> The fix was tested with JCK lang, vm, and api/java_lang tests, ute quick
>> tests, ute split_verifier tests, hotspot JTREG tests, and the test case
>> provided in the bug.
>>
>> Thanks, Harold
>>
>
>


-- 

[image: twitter-icon-large.png]

Keith McGuigan

@kamggg

kmcguigan at twitter.com