JDK-8240845 : test/hotspot/jtreg/serviceability/sa/ClhsdbCDSCore.java fails with "No long constant named "ZAddressSpaceStart" present in type database"
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc-agent
  • Affected Version: 15
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: linux
  • CPU: x86_64
  • Submitted: 2020-03-11
  • Updated: 2020-03-18
  • Resolved: 2020-03-17
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.
Other
tbdResolved
Related Reports
Duplicate :  
JDK-8220624 - SA: Out of sync with ZGC's internal data structures
Description
Exception in thread "main" java.lang.ExceptionInInitializerError
	at jdk.hotspot.agent/sun.jvm.hotspot.gc.z.ZAddress.is_weak_bad(ZAddress.java:43)
	at jdk.hotspot.agent/sun.jvm.hotspot.gc.z.ZAddress.is_weak_good_or_null(ZAddress.java:51)
	at jdk.hotspot.agent/sun.jvm.hotspot.gc.z.ZBarrier.is_weak_good_or_null_fast_path(ZBarrier.java:32)
	at jdk.hotspot.agent/sun.jvm.hotspot.gc.z.ZBarrier.weak_barrier(ZBarrier.java:76)
	at jdk.hotspot.agent/sun.jvm.hotspot.gc.z.ZCollectedHeap.oop_load_barrier(ZCollectedHeap.java:88)
	at jdk.hotspot.agent/sun.jvm.hotspot.gc.z.ZCollectedHeap.oop_load_at(ZCollectedHeap.java:102)
	at jdk.hotspot.agent/sun.jvm.hotspot.oops.OopField.getValueAsOopHandle(OopField.java:58)
	at jdk.hotspot.agent/sun.jvm.hotspot.oops.OopField.getValue(OopField.java:49)
	at jdk.hotspot.agent/sun.jvm.hotspot.oops.OopUtilities.threadOopGetParkBlocker(OopUtilities.java:308)
	at jdk.hotspot.agent/sun.jvm.hotspot.runtime.JavaThread.getCurrentParkBlocker(JavaThread.java:402)
	at jdk.hotspot.agent/sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:82)
	at jdk.hotspot.agent/sun.jvm.hotspot.runtime.DeadlockDetector.print(DeadlockDetector.java:39)
	at jdk.hotspot.agent/sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:62)
	at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$24.doit(CommandProcessor.java:1070)
	at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1986)
	at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1956)
	at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1836)
	at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:99)
	at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:40)
	at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:270)
	at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:406)
Caused by: java.lang.RuntimeException: No long constant named "ZAddressSpaceStart" present in type database
	at jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicTypeDataBase.lookupLongConstant(BasicTypeDataBase.java:113)
	at jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicTypeDataBase.lookupLongConstant(BasicTypeDataBase.java:106)
	at jdk.hotspot.agent/sun.jvm.hotspot.gc.z.ZGlobals.initialize(ZGlobals.java:93)
	at jdk.hotspot.agent/sun.jvm.hotspot.gc.z.ZGlobals.lambda$static$0(ZGlobals.java:65)
	at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:566)
	at jdk.hotspot.agent/sun.jvm.hotspot.gc.z.ZGlobals.<clinit>(ZGlobals.java:65)
	... 21 more
Comments
This test is already in ProblemList-zgc.txt. Must have been run without the problem list in place.
18-03-2020
Looks like SA support for ZGC is out of sync with the ZGC implementation. There is already a bug to cover this. See JDK-8220624. Maybe this should be closed as as dup. However, this test will need to be added to the ProblemList-zgc.txt. I think the reason it was not on there is because another recent bug fix enabled it to be run with ZGC, so this issue on recently became noticed. I think it was the fix for JDK-8232069 followed by JDK-8240691 that did this (in a round about way). I suggest a subtask to JDK-8220624 to get this test problem listed.
17-03-2020