RFR (XM) 8076579: Popping a stack frame after exception breakpoint sets last method param to exception

[Jaroslav Bachorik]

The fix looks ok as far as the change goes.

I'm relying on your analysis for the correctness.

-JB-

On 29.4.2015 11:48, serguei.spitsyn at oracle.com wrote:
> Ping...
> Just wanted to tell that it is a very safe and simple one-liner so that
> I assumed it to be reviewed in a couple of days, not weeks! :)
>
> Thanks!
> Serguei
>
> On 4/27/15 2:12 PM, serguei.spitsyn at oracle.com wrote:
>> Please, review the jdk 9 fix for:
>>   https://bugs.openjdk.java.net/browse/JDK-8076579
>>
>>
>> 9 hotspot webrev:
>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8076579-JVMTI-pop.1
>>
>>
>>
>> Summary:
>>
>>   This bug is a regression that was introduced but the fix of:
>>     https://bugs.openjdk.java.net/browse/JDK-7187554
>>
>>   The bug is in the InterpreterRuntime::member_name_arg_or_null()
>> function that
>>   does not return NULL if there is no invokestatic appendix argument
>> (MemberName).
>>   It is why the _remove_activation_preserving_args is trying to to
>> restore unexisting
>>   appendix argument when a pop instruction is executed by a debugger
>> in the debuggee VM.
>>   The fix is to correctly set NULL in the thread vm_result when it is
>> necessary:
>>     thread->set_vm_result(NULL);
>>
>>
>> Testing in progress:
>>   In progress: nsk.jvmti.testlist and nsk.jdi.testlist PopFrame tests,
>> JTREG com/sun/jdi tests,
>>                ad-hog ExceptionBug.java test from the bug report
>>
>>
>> Thanks,
>> Serguei
>