JDK-8157958 : AssertSafepointCheckConsistency2 fails with This lock should never have a safepoint check: SFPT_Test_lock
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 9
  • Priority: P2
  • Status: Closed
  • Resolution: Cannot Reproduce
  • Submitted: 2016-05-26
  • Updated: 2016-06-13
  • Resolved: 2016-06-13
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
Relates :  
JDK-8157957 - ClassNotFoundException: jdk.test.lib.JDKToolFinder
Description
hotspot/src/share/vm/runtime/mutex.cpp:899), pid=52456, tid=50688
#  assert(_safepoint_check_required != Monitor::_safepoint_check_never) failed: This lock should never have a safepoint check: SFPT_Test_lock

Current thread (0x01323400):  JavaThread "main" [_thread_in_vm, id=50688, stack(0x01110000,0x01160000)]

Stack: [0x01110000,0x01160000],  sp=0x0115f284,  free space=316k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [jvm.dll+0x5459a9]
V  [jvm.dll+0x545ea7]
V  [jvm.dll+0x1a3088]
V  [jvm.dll+0x429a27]
V  [jvm.dll+0x429c88]
V  [jvm.dll+0x563e67]
j  sun.hotspot.WhiteBox.assertMatchingSafepointCalls(ZZ)V+0
j  AssertSafepointCheckConsistency2.main([Ljava/lang/String;)V+10
v  ~StubRoutines::call_stub
V  [jvm.dll+0x290771]
V  [jvm.dll+0x455de5]
V  [jvm.dll+0x2903db]
V  [jvm.dll+0x30566a]
V  [jvm.dll+0x3009a5]
C  [java.exe+0x2c52]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  sun.hotspot.WhiteBox.assertMatchingSafepointCalls(ZZ)V+0
j  AssertSafepointCheckConsistency2.main([Ljava/lang/String;)V+10
v  ~StubRoutines::call_stub
Comments
Looks like a transient test execution failure.
13-06-2016
The SharedBaseAddress test was determined to be caused by the VM issuing a different error message to the set expected by the test.
02-06-2016
I agree with David. The child VM is supposed to crash here. The test is expecting exactly the output which is received, except somehow that output is not being caught by the parent VM and is instead causing the test to fail.
01-06-2016
Christian: the NoClassDefFoundError certainly seems key to this. Without the stream pumper we can't process the output of the VM that was launched. That VM is supposed to crash but we're supposed to recognize that.
01-06-2016
I don't think the NoClassDefFound Exceptions has anything to do with this. [~mockner] Can you see what went wrong in the AssertSafepointCheck test here?
31-05-2016
JDK-8157957 seems to be the same kind of problem.
26-05-2016
I don't think so... We would have seen it on more than one machine....
26-05-2016
There are a total of four failures in this test suite run. All four of these failures are reporting java.lang.NoClassDefFoundError errors. This looks like an environment problem to me.
26-05-2016
Is this an issue which the changes that just happened to the test library? I seem to recall a jdk testlibrary bug in recent days ...
26-05-2016
Leonid, can you assign this bug to the right person that can check out two things: 1) verify that the test machine does have a bad copy of the test library 2) check the right Aurora logs to see if there were any warnings or errors during the download process.
26-05-2016
Removing integration_blocker since this looks like a corrupt test library issue. Who is familiar with the Aurora download process to test machines? Is there someone who know which logs to check to see if there was a reported (but ignore) download error?
26-05-2016
So here's the problem as shown in the .jtr file: #section:main ----------messages:(4/169)---------- command: main AssertSafepointCheckConsistency2 reason: User specified action: run main AssertSafepointCheckConsistency2 Mode: othervm elapsed time (seconds): 0.896 ----------configuration:(3/71)---------- Boot Layer add exports: java.base/jdk.internal.misc ALL-UNNAMED ----------System.out:(1/775)*---------- Command line: [C:\\local\\aurora\\CommonData\\TEST_JAVA_HOME\\bin\\java.exe -cp C:\\local\\aurora\\sandbox\\results\\workDir\\classes\\0\\runtime\\Safepoint;C:\\local\\aurora\\CommonData\\j2se_jdk\\hotspot\\test\\runtime\\Safepoint;C:\\local\\aurora\\sandbox\\results\\workDir\\classes\\0\\testlibrary;C:\\local\\aurora\\CommonData\\j2se_jdk\\hotspot\\test\\testlibrary;C:\\local\\aurora\\sandbox\\results\\workDir\\classes\\0\\test\\lib;C:\\local\\aurora\\CommonData\\j2se_jdk\\test\\lib;C:\\local\\aurora\\CommonData\\jtreg_dir\\lib\\javatest.jar;C:\\local\\aurora\\CommonData\\jtreg_dir\\lib\\jtreg.jar -Xbootclasspath/a:. -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI -XX:-TransmitErrorReport -XX:-CreateCoredumpOnCrash -Xmx32m AssertSafepointCheckConsistency2 test ] ----------System.err:(20/1438)---------- java.lang.NoClassDefFoundError: jdk/test/lib/StreamPumper at jdk.test.lib.ProcessTools.getOutput(ProcessTools.java:65) at jdk.test.lib.OutputAnalyzer.<init>(OutputAnalyzer.java:50) at AssertSafepointCheckConsistency2.main(AssertSafepointCheckConsistency2.java:57) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-internal/Native Method) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-internal/NativeMethodAccessorImpl.java:62) at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-internal/DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(java.base@9-internal/Method.java:531) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) at java.lang.Thread.run(java.base@9-internal/Thread.java:843) Caused by: java.lang.ClassNotFoundException: jdk.test.lib.StreamPumper at jdk.internal.loader.BuiltinClassLoader.loadClass(java.base@9-internal/BuiltinClassLoader.java:366) at jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(java.base@9-internal/ClassLoaders.java:185) at java.lang.ClassLoader.loadClass(java.base@9-internal/ClassLoader.java:419) ... 9 more JavaTest Message: Test threw exception: java.lang.NoClassDefFoundError: jdk/test/lib/StreamPumper JavaTest Message: shutting down test STATUS:Failed.`main' threw exception: java.lang.NoClassDefFoundError: jdk/test/lib/StreamPumper This test actually failed due to the following: java.lang.NoClassDefFoundError: jdk/test/lib/StreamPumper However, the test intentionally crashes the VM via an assert() failure so DKFL sees and reports _all_ of the failure modes. Including the failure that is intentional.
26-05-2016
Yes it does. The test is small: /* * @test * @bug 8047290 * @summary Ensure that a Monitor::lock fires an assert when it incorrectly acqu ires a lock which must never have safepoint checks. * @library /testlibrary /test/lib * @modules java.base/jdk.internal.misc * java.management * @build AssertSafepointCheckConsistency2 * @run main ClassFileInstaller sun.hotspot.WhiteBox * sun.hotspot.WhiteBox$WhiteBoxPermission * @run main AssertSafepointCheckConsistency2 */ import jdk.test.lib.*; import sun.hotspot.WhiteBox; public class AssertSafepointCheckConsistency2 { public static void main(String args[]) throws Exception { if (args.length > 0) { WhiteBox.getWhiteBox().assertMatchingSafepointCalls(false, false); } if (Platform.isDebugBuild()){ ProcessBuilder pb = ProcessTools.createJavaProcessBuilder( "-Xbootclasspath/a:.", "-XX:+UnlockDiagnosticVMOptions", "-XX:+WhiteBoxAPI", "-XX:-TransmitErrorReport", "-XX:-CreateCoredumpOnCrash", "-Xmx32m", "AssertSafepointCheckConsistency2", "test"); OutputAnalyzer output = new OutputAnalyzer(pb.start()); output.shouldContain("assert").shouldContain("never"); } } } This part of the header is "interesting": @summary Ensure that a Monitor::lock fires an assert when it incorrectly acquires a lock which must never have safepoint checks. since that is exactly the failure mode that we are seeing.
26-05-2016
Does the test launch a second JVM? Is client still the default on windows 32-bit? I don't think we have stopped building client on windows yet so both would be present.
26-05-2016
Aurora shows quite a few failures for this test, but only one crash/assert failure. In the 2016-05-25 nightly, this failure only happened in one config: JDK: Java(TM) SE Runtime Environment 9 b0 (9-internal+0-2016-05-25-225352.jianzhou.9hs) Hotspot: Java HotSpot(TM) Server VM 9 b0 (9-internal+0-2016-05-25-225352.jianzhou.9hs) but now I'm really confused because the hs_err_pid shows this: A fatal error has been detected by the Java Runtime Environment: # # Internal Error (c:/jprt/T/P1/225352.jianzhou/s/hotspot/src/share/vm/runtime/mutex.cpp:899), pid=52456, tid=50688 # assert(_safepoint_check_required != Monitor::_safepoint_check_never) failed: This lock should never have a safepoint check: SFPT_Test_lock # # JRE version: Java(TM) SE Runtime Environment (9.0) (fastdebug build 9-internal+0-2016-05-25-225352.jianzhou.9hs) # Java VM: Java HotSpot(TM) Client VM (fastdebug 9-internal+0-2016-05-25-225352.jianzhou.9hs, mixed mode, serial gc, windows-x86) # CreateCoredumpOnCrash turned off, no core file dumped which clearly shows the crashing VM is a "Client VM". Huh?
26-05-2016