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

harold seigel harold.seigel at oracle.com
Thu Mar 19 01:26:20 UTC 2015


Hi Dean,

Thanks for your help.

Harold

On 3/18/2015 9:13 PM, Dean Long wrote:
> Hi Harold, this looks good now.  Thanks for adding the 
> IsolatedHandlerInTry test.
>
> dl
>
> On 3/18/2015 7:32 AM, harold seigel wrote:
>> 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