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

[harold seigel]

Hi David,

Thanks for the review.  I'll fix the copyright before pushing the change.

Harold

On 3/18/2015 10:05 PM, David Holmes wrote:
> 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
>>>
>>