JDK-8076579 : Popping a stack frame after exception breakpoint sets last method param to exception
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 7u80,8,9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2015-04-02
  • Updated: 2015-11-20
  • Resolved: 2015-04-30
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7 JDK 8 JDK 9
7u101Fixed 8u60Fixed 9 b66Fixed
Description
See https://netbeans.org/bugzilla/show_bug.cgi?id=251569

Use the attached class to reproduce the bug.

Run the class under debugger:
$ java -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=localhost:37535 -classpath ... exceptionbug.ExceptionBug

Then attach jdb:
$ jdb -attach localhost:37535

main[1] cont
> 
Exception occurred: java.lang.UnsupportedOperationException (uncaught)"thread=main", exceptionbug.ExceptionBug.criticalMethod(), line=26 bci=48

main[1] pop
main[1] step
> 
Step completed: "thread=main", exceptionbug.ExceptionBug.criticalMethod(), line=20 bci=0

main[1] print importantString
 importantString = "java.lang.UnsupportedOperationException: Kaboom!"
Comments
I'm re-targetting this bug to 9 as this must be fixed in jdk 9 first. I will create an 8u60 backport of this bug.
28-04-2015
[to Abhijit: ] This is an 8u60 bug, so the introduced in build must be related to 8, b104. The regression was most likely backported from 8 to 7u60. It looks like I have a fix for this issue. But the normal process is to fix it in this order: 9 => 8u => 7u. Please, let me know if it is NOT Ok for this sage of 7u80. If I understand it correctly, the 7u80 has been completed. If so, are there any plans for the next 7 update? I have no plans to backport the fix to the 7u and do rely on the Sustaining team.
22-04-2015
Forgot to tell about the 8 regression that came with the b104. This is the email that lists the fix of JDK-7187554 (the same as the 7u60 b08 does): hs25-b46 has been integrated into jdk8-b104. http://hg.openjdk.java.net/jdk8/jdk8/rev/ceefd94ef326 http://hg.openjdk.java.net/jdk8/jdk8/corba/rev/d411c60a8c2f http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/104743074675 http://hg.openjdk.java.net/jdk8/jdk8/jaxp/rev/a22fe9bd01e6 http://hg.openjdk.java.net/jdk8/jdk8/jaxws/rev/42211ab0ab1c http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/f1d8d15bfcb5 http://hg.openjdk.java.net/jdk8/jdk8/langtools/rev/dd4a00c220c6 http://hg.openjdk.java.net/jdk8/jdk8/nashorn/rev/afc100513451 Component : VM Status : 0 major failures, 0 minor failures Date : 08/20/2013 at 21:57 Tested By : VM SQE &leonid.mesnik@oracle.com Cost(total man-days): 1 Workspace : Bundles : Platforms : Others Tests :/net/sqenfs-1.sfbay/export1/comp/vm/testbase/ Browsers : NA Patches : NA Logs : none Number of Tests Executed : 0 product tests, 0 unit tests, 0 tck tests Bug verification status: ====================================== Tested, Pass: Tested, Pass (partial fixes): Tested, Fail: Untested bug fixes: Setup is not available: 7187554: JSR 292: JVMTI PopFrame needs to handle appendix arguments 8009728: nsk/jvmti/AttachOnDemand/attach030 crashes on Win32 8016601: Unable to build hsx24 on Windows using project creator and Visual Studio 8019583: [TESTBUG] runtime/7107135 always passes 8019915: whitebox testClearMethodStateTest fails with tiered on sparc 8020598: ObjectCountEventSender::send needs INCLUDE_TRACE guards when building OpenJDK with INCLUDE_TRACE=0 8021771: warning stat64 is deprecated - when building on OSX 10.7.5 8022093: syntax error near "umpiconninfo_t" -- when building on Solaris 10 8022188: Make zero compile after 8016131 and 8016697 8022284: Hide internal data structure in PhaseCFG 8022452: Hotspot needs to know about Windows 8.1 and Windows Server 2012 R2 8022475: Remove unneeded ad-files 8022688: new hotspot build - hs25-b46 8022740: Visual 2008 IDE build is broken 8022800: Use specific generations rather than generation iteration 8022880: False sharing between PSPromotionManager instances 8022899: SunStudio compiler can not handle EXCEPTION_MARK and inlining 8022993: Convert MAX_UNROLL constant to LoopMaxUnroll C2 flag 8023021: Unnecessary clearing of the card table introduced by the fix for JDK-8023013 Build change only: New bugs filed: Bugs in PIT build: Bugs in earlier promoted build: Number of PIT requested: 1 Integration target J2SE build number: 1.8.0-b104. Issues and Notes: This is PIT for HS25 b46 for JDK 8 b104.
22-04-2015
[to Abhijit: ] I'm thinking how to identify all Hotspot fixes that were pushed into 7u60 b08 and 8 b104. One way is to look at the email sent to the jdk7u-dev@openjdk.java.net with the subject "jdk7u-b08: jdk7u60-dev" that tells this: http://hg.openjdk.java.net/jdk7u/jdk7u60/rev/1af056061146 http://hg.openjdk.java.net/jdk7u/jdk7u60/langtools/rev/be8e34e4920e http://hg.openjdk.java.net/jdk7u/jdk7u60/jdk/rev/0dd27693876d http://hg.openjdk.java.net/jdk7u/jdk7u60/jaxws/rev/d3896e59b04d http://hg.openjdk.java.net/jdk7u/jdk7u60/jaxp/rev/b19c0f18b5a5 http://hg.openjdk.java.net/jdk7u/jdk7u60/hotspot/rev/a198787e7b9b http://hg.openjdk.java.net/jdk7u/jdk7u60/corba/rev/8469bc00ddca --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-7187554 hotspot JSR 292: JVMTI PopFrame needs to handle appendix arguments JDK-8007037 hotspot JSR 292: the VM_RedefineClasses::append_entry() should do cross-checks with indy operands JDK-8008511 hotspot JSR 292: MemberName vmtarget refs to methods must be updated at class redefinition JDK-8013945 hotspot CMS fatal error: must own lock MemberNameTable_lock JDK-8014052 hotspot JSR292: assert(end_offset == next_offset) failed: matched ending JDK-8014288 hotspot perf regression in nashorn JDK-8008448.js test after 8008511 changes JDK-8023004 hotspot JSR 292: java.lang.RuntimeException: Original target method was called. JDK-8033487 hotspot Improve GC option handling The suspect is JDK-7187554 with the changeset: http://hg.openjdk.java.net/jdk7u/jdk7u60/hotspot/rev/a198787e7b9b
21-04-2015
The issue is reproducible on the 7u60 but not on the 7u40 and 7 fcs. This is the 7u60 build where the issue started to appear: /java/re/jdk/1.7.0_60/promoted/all/b08 The build /java/re/jdk/1.7.0_60/promoted/all/b07 does not fail with this pattern. The 8 started to fail in the build: /java/re/jdk/1.8.0/promoted/all/b104 The build /java/re/jdk/1.8.0/promoted/all/b104 does not fail with this pattern.
21-04-2015
The same issue is present in the 7u80. So that this problem is not a regression in 8u.
17-04-2015
Interesting that the test does not fail if executed with -Xcomp but always fails with -Xint and -Xmixed. It proves, this is a JVMTI issue. Exactly the same behavior is observed on Solaris sparc.
17-04-2015
$ cat ExceptionBug.java public class ExceptionBug { /** * @param args the command line arguments */ public static void main(String[] args) { criticalMethod("Arg1", "Arg2", "Arg3"); } private static void criticalMethod(String arg1, String arg2, String arg3){ String loc = "Kaboom!"; System.out.println(arg1.getClass().getName()); String criticalResult = arg1.trim(); System.out.println(criticalResult.getClass().getName()); if (criticalResult.isEmpty()){ return; } throw new UnsupportedOperationException(loc); } } Start the ExceptionBug program: $ $JAVA_HOME/bin/java -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=localhost:37535 -classpath . ExceptionBug Start the jdb: $JAVA_HOME/bin/jdb -attach localhost:37535 Set uncaught java.lang.Throwable Set deferred uncaught java.lang.Throwable Initializing jdb ... VM Started: > No frames on the current call stack main[1] cont > Exception occurred: java.lang.UnsupportedOperationException (uncaught)"thread=main", ExceptionBug.criticalMethod(), line=19 bci=53 19 throw new UnsupportedOperationException(loc); main[1] pop main[1] step > Step completed: "thread=main", ExceptionBug.criticalMethod(), line=12 bci=0 12 String loc = "Kaboom!"; main[1] main[1] print arg1 arg1 = "Arg1" main[1] print arg2 arg2 = "Arg2" main[1] print arg3 arg3 = "java.lang.UnsupportedOperationException: Kaboom!" main[1] As we see, the last argument was restored incorrectly when the frame was popped.
16-04-2015
This bug is reproducible. In fact, the last method argument is set to "Kaboom!", not the first. It is the only argument, and so, the last is also the first. :) I suspect the issue is in the JVMTI PopFrame implementation. Most likely, it is in the interpreter remove_activation_preserving_args entry point which is used for both exception handling and PopFrame. However, I need to double check this before moving the bug to the hotspot/jvmti sub-category.
16-04-2015