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

[Dean Long]

On 7/24/2014 12:32 PM, harold seigel wrote:
> Hi Dean,
>
> Yes, a pathological bytecode sequence could cause a native stack 
> overflow.  But there are probably multiple pathological bytecode 
> sequences that could cause the JVM to run out of other resources.
>
I can't think of another case, but I would hope we would throw an 
appropriate exception, such as OutOfMemoryError, in those cases.
However, for this change, wouldn't it be trivial to write a test case 
that would crash the verifier 100% of the time?
If so, then I think a non-recursive iterative solution is more appropriate.

Looks like an unconditional "goto" backwards branch doesn't cause us to 
stop processing the next bytecode, even though
it's not reachable.

It would be good to have some test cases, (perhaps written in JASM?), 
that cover all the relevant cases.

dl

> The purpose of this fix is to allow well behaved tools such as 
> NetBeans Profiler to work but also prevent malformed objects from 
> being returned by constructors.
>
> Harold
> On 7/24/2014 2:44 PM, Dean Long wrote:
>> 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
>>
>