P4
The issue has been reported by Andrew Leonard from IBM (Java Runtimes Development):
If during the JDWP setup initialization the VM initialization takes slightly longer than the main debug initialization thread a "hang" situation can occur. This has been seen in testcase test.jck8b.runtime.vm.jdwp and can also be recreated easily by adding a 10 second sleep to the beginning of the src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.c method eventHelper_reportVMInit() .
This is some additional details from Andrew on how to reproduce this problem:
. . .
I had a chat with one of my colleagues who could recreate it, and it's probably related to the handshaking that is done in the particular scenario. So with the JCK harness:
com.sun.jck.lib.ExecJCKTestOtherJVMCmd LD_LIBRARY_PATH=/javatest/lib/jck/jck8b/natives/linux_x86-64 /projects/jck/jdwp/j2sdk-image/bin/java -Xdump:system:none -Xdump:system:events=gpf+abort+traceassert+corruptcache -Xdump:snap:none -Xdump:snap:events=gpf+abort+traceassert+corruptcache -Xdump:java:none -Xdump:java:events=gpf+abort+traceassert+corruptcache -Xdump:heap:none -Xdump:heap:events=gpf+abort+traceassert+corruptcache -Xfuture -agentlib:jdwp=server=y,transport=dt_socket,address=localhost:35000,suspend=y -classpath /javatest/lib/jck/JCK8b-b03/JCK-runtime-8b/classes -Djava.security.policy=/javatest/lib/jck/JCK8b-b03/JCK-runtime-8b/lib/jck.policy javasoft.sqe.jck.lib.jpda.jdwp.DebuggeeLoader -waittime=600 -msgSwitch=ub1604x64vm10:38636 -componentName=ArrayReference.GetValues.getvalues002
Note that the JCK test harness starts the target process, attaches to it, and sends the resume command
in a very short time with no handshaking.
That may not help..but hopefully helps explain things a bit? It's the timing of the resume command during the test that is crucial, resuming before the VM initialization is complete will trigger it.
Thanks
Andrew
If during the JDWP setup initialization the VM initialization takes slightly longer than the main debug initialization thread a "hang" situation can occur. This has been seen in testcase test.jck8b.runtime.vm.jdwp and can also be recreated easily by adding a 10 second sleep to the beginning of the src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.c method eventHelper_reportVMInit() .
This is some additional details from Andrew on how to reproduce this problem:
. . .
I had a chat with one of my colleagues who could recreate it, and it's probably related to the handshaking that is done in the particular scenario. So with the JCK harness:
com.sun.jck.lib.ExecJCKTestOtherJVMCmd LD_LIBRARY_PATH=/javatest/lib/jck/jck8b/natives/linux_x86-64 /projects/jck/jdwp/j2sdk-image/bin/java -Xdump:system:none -Xdump:system:events=gpf+abort+traceassert+corruptcache -Xdump:snap:none -Xdump:snap:events=gpf+abort+traceassert+corruptcache -Xdump:java:none -Xdump:java:events=gpf+abort+traceassert+corruptcache -Xdump:heap:none -Xdump:heap:events=gpf+abort+traceassert+corruptcache -Xfuture -agentlib:jdwp=server=y,transport=dt_socket,address=localhost:35000,suspend=y -classpath /javatest/lib/jck/JCK8b-b03/JCK-runtime-8b/classes -Djava.security.policy=/javatest/lib/jck/JCK8b-b03/JCK-runtime-8b/lib/jck.policy javasoft.sqe.jck.lib.jpda.jdwp.DebuggeeLoader -waittime=600 -msgSwitch=ub1604x64vm10:38636 -componentName=ArrayReference.GetValues.getvalues002
Note that the JCK test harness starts the target process, attaches to it, and sends the resume command
in a very short time with no handshaking.
That may not help..but hopefully helps explain things a bit? It's the timing of the resume command during the test that is crucial, resuming before the VM initialization is complete will trigger it.
Thanks
Andrew