JDK-8152686 : com/sun/jdi/OomDebugTest.java fails with java.lang.reflect.InvocationTargetException
  • Type: Bug
  • Component: core-svc
  • Sub-Component: debugger
  • Affected Version: 9
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2016-03-24
  • Updated: 2016-04-11
  • Resolved: 2016-04-07
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 9
9Resolved
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Description
com/sun/jdi/OomDebugTest.java failing in hs nightly testing with "java.lang.reflect.InvocationTargetException"
Comments
Removed integration_blocker label since closed as duplicate. (Duplicates are not blockers.)
11-04-2016

Closing as a duplicate of the bug used to backout the test.
07-04-2016

This test was backed out via JDK-8153673.
07-04-2016

[To Amit: ] I re-assigned this bug to myself. I hpe, you are Ok with this. It is a regression that could be a result of the fix I sponsored. Also, it is related and may have the same root cause as some other bugs that I'm investigating now.
06-04-2016

Now I think, this is not a regression introduced by the fix of: https://bugs.openjdk.java.net/browse/JDK-4858370 This fix just added new test case that started failing intermittently because of a pre-existing bug. I think this way because there is another test case that started failing with a very similar manifestation before the push of the JDK-4858370. I'm talking about the bug: https://bugs.openjdk.java.net/browse/JDK-8152586 I'm in process of isolating the push that introduced the JDK-8152586 bug.
05-04-2016

Occurs on JDK 9 with -XX:+UseParallelGC for the debuggee as well. This being caused by (some) GC seems a red herring. Command Line: -Xmx40m -XX:+UseParallelGC -Xdebug -Xrunjdwp:transport=dt_socket,address=localhost:46002,suspend=y OomDebugTestTarget test1 OomDebugTestTarget Host: Intel(R) Core(TM) i7-4900MQ CPU @ 2.80GHz, 8 cores, 15G, Fedora release 23 (Twenty Three) Time: Mon Apr 4 20:20:21 2016 CEST elapsed time: 0 seconds (0d 0h 0m 0s) --------------- T H R E A D --------------- Current thread (0x00007f96fc011000): JavaThread "main" [_thread_in_vm, id=10093, stack(0x00007f9703e44000,0x00007f9703f45000)] Stack: [0x00007f9703e44000,0x00007f9703f45000], sp=0x00007f9703f43540, free space=1021k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x7965f4] alloc_object(_jclass*, Thread*) [clone .constprop.85]+0x14 V [libjvm.so+0x7a4a61] jni_NewObjectA+0xa1 C [libjdwp.so+0x1bbd6] invoker_doInvoke+0x286 C [libjdwp.so+0x14cf5] reportEvents.part.2+0x165 C [libjdwp.so+0x14ff0] event_callback+0x1e0 C [libjdwp.so+0x17e17] cbBreakpoint+0xb7 V [libjvm.so+0x86019a] JvmtiExport::post_raw_breakpoint(JavaThread*, Method*, unsigned char*)+0x2aa V [libjvm.so+0x77b7bf] InterpreterRuntime::_breakpoint(JavaThread*, Method*, unsigned char*)+0x1f j OomDebugTestTarget.entry()V+0 j OomDebugTestTarget.main([Ljava/lang/String;)V+15 v ~StubRoutines::call_stub V [libjvm.so+0x78887a] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x45a V [libjvm.so+0x7a84c2] jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*) [clone .isra.69] [clone .constprop.92]+0x1d2 V [libjvm.so+0x7aad3f] jni_CallStaticVoidMethod+0x19f C [libjli.so+0x9870] JavaMain+0x860 C [libpthread.so.0+0x760a] start_thread+0xca
04-04-2016

It seems to reproduce on JDK 8 with -XX:+UseG1GC for the debuggee: DEBUG: invoked constructor # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007f0b801db497, pid=13132, tid=0x00007f0b81886700 # # JRE version: OpenJDK Runtime Environment (8.0) (build 1.8.0-internal-sgeholf_2016_03_29_14_10-b00) # Java VM: OpenJDK 64-Bit Server VM (25.71-b00 mixed mode linux-amd64 compressed oops) # Problematic frame: # V [libjvm.so+0x64e497] alloc_object(_jclass*, Thread*) [clone .constprop.86]+0x7 # # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk8u-dev/JTwork/scratch/hs_err_pid13132.log # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # ----------System.err:(28/1635)---------- run args: [OomDebugTestTarget, test5, OomDebugTestTarget] java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at OomDebugTest.runTests(OomDebugTest.java:133) at TestScaffold.startTests(TestScaffold.java:429) at OomDebugTest.main(OomDebugTest.java:304) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) at java.lang.Thread.run(Thread.java:745) Caused by: com.sun.jdi.VMDisconnectedException at com.sun.tools.jdi.TargetVM.waitForReply(TargetVM.java:304) at com.sun.tools.jdi.VirtualMachineImpl.waitForTargetReply(VirtualMachineImpl.java:1036) at com.sun.tools.jdi.PacketStream.waitForReply(PacketStream.java:69) at com.sun.tools.jdi.JDWP$ClassType$NewInstance.waitForReply(JDWP.java:3506) at com.sun.tools.jdi.ClassTypeImpl.newInstance(ClassTypeImpl.java:210) at OomDebugTest.test5(OomDebugTest.java:239) ... 13 more
04-04-2016

So far I wasn't able to reproduce this on JDK 8u (3 runs, 150 test invocations each). [EDIT] With default GC config for the debuggee
04-04-2016

Here is another failure case output: command: main OomDebugTest OomDebugTestTarget test5 reason: User specified action: run main OomDebugTest OomDebugTestTarget test5 elapsed time (seconds): 2.842 ----------System.out:(26/940)---------- vmOpts: '-Xmx40m' javaOpts: '' JVM version:9-internal JDI version: 9.0 JVM description: Java Debug Interface (Reference Implementation) version 9.0 Java Debug Wire Protocol (Reference Implementation) version 9.0 JVM Debug Interface version 9.0 JVM version 9-internal (OpenJDK 64-Bit Server VM, mixed mode, sharing) DEBUG: OomDebugTestTarget.main DEBUG: invoked constructor DEBUG: ------------> Running test5 DEBUG: invoked constructor DEBUG: invoked constructor DEBUG: invoked constructor DEBUG: invoked constructor DEBUG: invoked constructor DEBUG: invoked constructor DEBUG: invoked constructor DEBUG: invoked constructor DEBUG: invoked constructor DEBUG: invoked constructor DEBUG: invoked constructor DEBUG: invoked constructor DEBUG: invoked constructor JDWP exit error AGENT_ERROR_ILLEGAL_ARGUMENT(202): saveGlobalRef obj [util.c:60] FATAL ERROR in native method: JDWP saveGlobalRef obj, jvmtiError=AGENT_ERROR_ILLEGAL_ARGUMENT(202) ----------System.err:(28/1771)---------- [4ms] run args: [OomDebugTestTarget, test5, OomDebugTestTarget] java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base/Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(java.base/NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base/DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(java.base/Method.java:531) at OomDebugTest.runTests(OomDebugTest.java:132) at TestScaffold.startTests(TestScaffold.java:431) at OomDebugTest.main(OomDebugTest.java:304) at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base/Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(java.base/NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base/DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(java.base/Method.java:531) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) at java.lang.Thread.run(java.base/Thread.java:804) Caused by: com.sun.jdi.VMDisconnectedException at com.sun.tools.jdi.TargetVM.waitForReply(jdk.jdi/TargetVM.java:304) at com.sun.tools.jdi.VirtualMachineImpl.waitForTargetReply(jdk.jdi/VirtualMachineImpl.java:1088) at com.sun.tools.jdi.PacketStream.waitForReply(jdk.jdi/PacketStream.java:69) at com.sun.tools.jdi.JDWP$ClassType$NewInstance.waitForReply(jdk.jdi/JDWP.java:3609) at com.sun.tools.jdi.ClassTypeImpl.newInstance(jdk.jdi/ClassTypeImpl.java:210) at OomDebugTest.test5(OomDebugTest.java:238) ... 13 more
04-04-2016

relevant hs_err.log file.
04-04-2016

I was able to reproduce this on JDK 9, Linux x86_64 with: $ for i in $(seq 150); do echo $i; JT_JAVA=./build/linux-x86_64-normal-server-release/jdk jtreg jdk/test/com/sun/jdi/OomDebugTest.java || break; done [...] 20 Test results: passed: 1 Report written to /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-hs-rt/JTreport/html/report.html Results written to /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-hs-rt/JTwork 21 Test results: passed: 1 Report written to /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-hs-rt/JTreport/html/report.html Results written to /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-hs-rt/JTwork 22 Test results: failed: 1 The report says this (this time in test5 of OomDebugTest): DEBUG: invoked constructor DEBUG: invoked constructor # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007fa7b10595f4, pid=21043, tid=21044 # # JRE version: OpenJDK Runtime Environment (9.0) (build 9-internal+0-2016-04-04-111346.sgehwolf.openjdk9-hs-rt) # Java VM: OpenJDK 64-Bit Server VM (9-internal+0-2016-04-04-111346.sgehwolf.openjdk9-hs-rt, mixed mode, tiered, compressed oops, g1 gc, linux-amd64) # Problematic frame: # V [libjvm.so+0x7965f4] alloc_object(_jclass*, Thread*) [clone .constprop.85]+0x14 # # Core dump will be written. Default location: Core dumps may be processed with "/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t %P %I" (or dumping to /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-hs-rt/JTwork/scratch/core.21043) # # An error report file with more information is saved as: # /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-hs-rt/JTwork/scratch/hs_err_pid21043.log # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # ----------System.err:(28/1771)---------- [3ms] run args: [OomDebugTestTarget, test5, OomDebugTestTarget] java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base/Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(java.base/NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base/DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(java.base/Method.java:531) at OomDebugTest.runTests(OomDebugTest.java:132) at TestScaffold.startTests(TestScaffold.java:431) at OomDebugTest.main(OomDebugTest.java:304) at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base/Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(java.base/NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base/DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(java.base/Method.java:531) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) at java.lang.Thread.run(java.base/Thread.java:804) Caused by: com.sun.jdi.VMDisconnectedException at com.sun.tools.jdi.TargetVM.waitForReply(jdk.jdi/TargetVM.java:304) at com.sun.tools.jdi.VirtualMachineImpl.waitForTargetReply(jdk.jdi/VirtualMachineImpl.java:1088) at com.sun.tools.jdi.PacketStream.waitForReply(jdk.jdi/PacketStream.java:69) at com.sun.tools.jdi.JDWP$ClassType$NewInstance.waitForReply(jdk.jdi/JDWP.java:3609) at com.sun.tools.jdi.ClassTypeImpl.newInstance(jdk.jdi/ClassTypeImpl.java:210) at OomDebugTest.test5(OomDebugTest.java:238) ... 13 more JavaTest Message: Test threw exception: java.lang.reflect.InvocationTargetException JavaTest Message: shutting down test
04-04-2016

Was able to reproduce this failure on linux-x64 machine in server mode. It is failing intermittently. The failure can be reproduced in hundreds of runs on linux-x64 with -Xmixed config. I'll check if the -Xcomp can simplify the failure reproduction.
01-04-2016

The com/sun/jdi/OomDebugTest.java was recently added with the fix for: https://bugs.openjdk.java.net/browse/JDK-4858370 It can be a bug in the test that causes the test to fail. Also, it can be a regression introduced in this fix in the JDI. If one of this is true then it is a debugger bug. It is relatively easy to check if this failure is reliably reproducible: - revert the fix of 4858370 in the src/jdk.jdwp.agent/share/native/libjdwp/invoker.c - check if it stopped failing Ok, my suggestion above does not work. If the fix is reverted then the test fails with an OOM Exception in target VM.
01-04-2016

ILW = M (test failure) H (seen multiple times) H (no workaround) = P2
31-03-2016