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

[harold seigel]

Hi Dean,

Thanks for catching this case.  The fix needs to be improved to handle 
cases where the handler's throw is done from inside a TRY block.

Harold

On 7/29/2014 5:43 PM, Dean Long wrote:
> Does the verifier require try/catch to be properly nested?  If not, 
> you could have:
>
>   public TryInit() {
>       try {
>           super();
>           xxxx();
>       } catch(Exception e) {
>           // try 1 start
>           throw e;
>           // try 1 end
>       }
>       xxxx();
>       // catch 1 start
>   }
>
> where the improperly nested "try 1/catch 1" causes the throw to branch
> to "catch 1" and ultimately be ignored.  Or how about a properly
> nested try/catch that caused the throw to be ignored:
>
>   public TryInit() {
>       try {
>           super();
>           xxxx();
>       } catch(Exception e) {
>           try {
>             throw e;
>           } catch(Exception e) {}
>       }
>       xxxx();
>   }
>
> In either case, I guess you need to make sure the throw is not inside a
> try block.
>
> By the way, do you have a pointer to the relevant language in the 
> verifier spec?
>
> 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
>>
>