RFR(XS) 8075118: JVM stuck in infinite loop during verification

harold seigel harold.seigel at oracle.com
Tue Mar 17 19:13:53 UTC 2015

Hi Dean,

I see your point.  Instead of this fix, I may try instead keeping a 
separate list of handlers that have been scanned and not push a handler 
on the stack if it has already been scanned.


On 3/17/2015 3:06 PM, Dean Long wrote:
> Hi Harold.  How does this change guarantee that the catch handler is 
> always scanned? If it was an island of code surrounded by gotos, so 
> that it is only reachable through the handler, then it looks like it 
> will now be skipped entirely.
> dl
> On 3/17/2015 11:37 AM, harold seigel wrote:
>> Hi,
>> Please review this fix for bug JDK-8075118.  The code being verified 
>> contained a TRY block whose catch handler was inside the TRY block. 
>> Function ClassVerifier::ends_in_throw() scans the bytecodes in a TRY 
>> block and then scans the bytecodes in the TRY block's handler and 
>> then scans the bytecodes of its handler's handler, etc.  Since, the 
>> bytecodes in the handler and the bytecode's handler's handler were 
>> the same, it just kept scanning the same bytecodes over and over.
>> The fix prevents re-scanning a handler's bytecodes if they are 
>> contained in the TRY block.
>> Open webrev: http://cr.openjdk.java.net/~hseigel/jdk9_16Mar_8075118/
>> JBS Bug:  https://bugs.openjdk.java.net/browse/JDK-8075118
>> The fix was tested with the test program provided by the bug, the JCK 
>> Lang, VM, and API tests, the testbase quick and split verifier tests, 
>> and with the JTREG hotspot tests.
>> Thanks! Harold

More information about the hotspot-runtime-dev mailing list