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

[Dean Long]

It looks like, given a pathological bytecode sequence, that the 
recursion would be limited only by the length of the
bytecode sequence.  Couldn't this cause a native stack overflow crash?

dl

On 7/24/2014 10:55 AM, 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