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

Dean Long dean.long at oracle.com
Thu Mar 19 01:13:27 UTC 2015


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