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

Dean Long dean.long at oracle.com
Tue Jul 29 22:28:31 UTC 2014


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
>



More information about the hotspot-runtime-dev mailing list