RFR(XS) 8075118: JVM stuck in infinite loop during verification
David Holmes
david.holmes at oracle.com
Thu Mar 19 02:05:47 UTC 2015
Hi Harold,
On 19/03/2015 12: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 fix looks okay to me.
The new test files need the OpenJDK copyright notice, not Oracle one.
Thanks,
David
> 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