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

harold seigel harold.seigel at oracle.com
Wed Mar 18 14:32:11 UTC 2015


Hi,

Please review this new fix for JDK-8075118.  This fix keeps a list of 
catch handlers that have been scanned to prevent the infinite loop 
described below.  This change removes the previous fix's check if  the 
catch handler is inside the TRY block, preventing the problem that Dean 
brought up.

The webrev includes 2 tests, HandlerInTry.jasm, that is based on the 
test case provided in the bug, that caused the infinite loop.  And, 
IsolatedHandlerInTry.jasm, that tests a catch handler that is inside its 
TRY block but only reachable as a handler.

Open webrev: http://cr.openjdk.java.net/~hseigel/jdk9_16Mar_8075118.2/

The new 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, the JTREG hotspot tests, and with the two tests described above.

Thanks, Harold

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