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

Dean Long dean.long at oracle.com
Tue Jul 29 21:43:36 UTC 2014


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
>



More information about the hotspot-runtime-dev mailing list