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

Coleen Phillimore coleen.phillimore at oracle.com
Wed Apr 29 13:01:19 UTC 2015

Serguei,

The bug says JSR292 and PopFrame! I think we are all scared of it.

The fix looks good. Nit: I would have coded it in an 'else' statement instead. I did check that this is the only interpreter runtime function without all paths setting vm_result.

You are going to have to get someone from the compiler team who knows JSR292 to also review it.

thanks, Coleen

On 4/29/15, 5:48 AM, 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::membernameargornull() function that does not return NULL if there is no invokestatic appendix argument (MemberName). It is why the removeactivationpreservingargs 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 vmresult when it is necessary: thread->setvmresult(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

More information about the hotspot-dev mailing list