RFR 8050485: super() in a try block in a ctor causes VerifyError

[harold seigel]

Hi Dean,

Thanks for finding this problem.  I will look into issues with backward 
branches.  Perhaps, if I scan every forward path, backward branches can 
be ignored.

Harold

On 7/29/2014 6:28 PM, Dean Long wrote:
> Checking the algorithm, it looks like there is a change of an infinite 
> loop:
>
> L0:
> goto L2           // 2: set_interval(L2, code_length);
> start_bc_offset:
> L2:
> ifle L0           // 1: set_interval(L0, L2)
> L3:
> code_length:
>
> dl
>
> On 7/29/2014 9:47 AM, harold seigel wrote:
>> Hi,
>>
>> Please review this updated webrev for bug 8050485.  This update does 
>> not use recursion.  Instead, it uses a GrowableArray to push and pop 
>> bytecode intervals when parsing if*, goto*, tableswitch, lookupswitch 
>> and athrow bytecodes.  This updated webrev was tested using the same 
>> tests as the previous weberv.
>>
>> The updated webrev is at: 
>> http://cr.openjdk.java.net/~hseigel/bug_8050485_2/
>>
>> Thanks, Harold
>>
>> On 7/24/2014 1:55 PM, harold seigel wrote:
>>> Hi,
>>>
>>> Please review this verifier fix for bug 8050485.
>>>
>>> The fix for JDK-8035119 
>>> <https://bugs.openjdk.java.net/browse/JDK-8035119> broke existing 
>>> tools, such as NetBeans Profiler, that generate bytecodes which 
>>> place TRY blocks around constructor calls to super() and this().  
>>> The purpose of that fix was to prevent exception handlers from 
>>> handling exceptions thrown from super() and this(), and returning 
>>> malformed objects to the callers of the constructors.
>>>
>>> The NB Profiler prevents malformed objects from being returned to 
>>> the constructors' callers by having the exception handlers re-throw 
>>> the exceptions.
>>>
>>> The purpose of this fix is to allow a TRY block around a 
>>> constructor's call to super() and this(), provided that all code 
>>> paths in the TRY block's exception handlers terminate with a throw. 
>>> This prevents malformed objects from being returned and does not 
>>> break tools like NB Profiler.
>>>
>>> The fix works by parsing the bytecodes inside of the exception 
>>> handlers, making sure that all code paths end in an 'athrow' 
>>> bytecode.  Otherwise, it throws a VerifyError exception.  This 
>>> parsing is only done when the verifier detects a constructor's call 
>>> to super() or this() from inside of a TRY block.
>>>
>>> Bug:  https://bugs.openjdk.java.net/browse/JDK-8050485
>>> Open webrev: http://cr.openjdk.java.net/~hseigel/bug_8050485/
>>>
>>> The fix was tested with the JCK lang, vm, and api/java_lang tests, 
>>> the UTE verifier and quick tests, the JTREG hotspot tests, and 
>>> additional tests with constructor calls to super() and this() from 
>>> inside of a TRY block, including one provided by NB Profiler.
>>>
>>> Thanks, Harold
>>
>