JDK-8270202 : ZGC: serviceability/sa/TestJmapCore.java fails with UnmappedAddressException
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc-agent
  • Affected Version:
    17.0.7-oracle,18,20,21-pool-oracle,22 17.0.7-oracle,18,20,21-pool-oracle,22
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: linux,os_x
  • CPU: x86_64,aarch64
  • Submitted: 2021-07-09
  • Updated: 2024-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.
Other
tbdUnresolved
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Sub Tasks
JDK-8271863 :  
JDK-8327424 :  
Description
The following test failed in the JDK18 CI:

serviceability/sa/TestJmapCore.java

Here's a snippet from the log file:

----------System.err:(53/4095)----------
sun.jvm.hotspot.debugger.UnmappedAddressException: 7f3bc0774000
	at jdk.hotspot.agent/sun.jvm.hotspot.debugger.PageCache.checkPage(PageCache.java:208)
	at jdk.hotspot.agent/sun.jvm.hotspot.debugger.PageCache.getData(PageCache.java:63)
	at jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readBytes(DebuggerBase.java:225)
	at jdk.hotspot.agent/sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.readCInteger(LinuxDebuggerLocal.java:565)
	at jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readAddressValue(DebuggerBase.java:462)
	at jdk.hotspot.agent/sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.readAddress(LinuxDebuggerLocal.java:500)
	at jdk.hotspot.agent/sun.jvm.hotspot.debugger.linux.LinuxAddress.getAddressAt(LinuxAddress.java:73)
	at jdk.hotspot.agent/sun.jvm.hotspot.gc.z.ZGranuleMapForForwarding.at(ZGranuleMapForForwarding.java:67)
	at jdk.hotspot.agent/sun.jvm.hotspot.gc.z.ZGranuleMapForForwarding.get(ZGranuleMapForForwarding.java:72)
	at jdk.hotspot.agent/sun.jvm.hotspot.gc.z.ZForwardingTable.get(ZForwardingTable.java:58)
	at jdk.hotspot.agent/sun.jvm.hotspot.gc.z.ZHeap.relocate_object(ZHeap.java:96)
	at jdk.hotspot.agent/sun.jvm.hotspot.gc.z.ZBarrier.relocate(ZBarrier.java:44)
	at jdk.hotspot.agent/sun.jvm.hotspot.gc.z.ZBarrier.relocate_or_remap(ZBarrier.java:57)
	at jdk.hotspot.agent/sun.jvm.hotspot.gc.z.ZBarrier.weak_load_barrier_on_oop_slow_path(ZBarrier.java:36)
	at jdk.hotspot.agent/sun.jvm.hotspot.gc.z.ZBarrier.weak_barrier(ZBarrier.java:69)
	at jdk.hotspot.agent/sun.jvm.hotspot.gc.z.ZCollectedHeap.oop_load_barrier(ZCollectedHeap.java:91)
	at jdk.hotspot.agent/sun.jvm.hotspot.gc.z.ZCollectedHeap.oop_load_in_native(ZCollectedHeap.java:112)
	at jdk.hotspot.agent/sun.jvm.hotspot.oops.VMOopHandle.resolve(VMOopHandle.java:60)
	at jdk.hotspot.agent/sun.jvm.hotspot.oops.Klass.getJavaMirror(Klass.java:114)
	at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter$5.visit(HeapHprofBinWriter.java:1140)
	at jdk.hotspot.agent/sun.jvm.hotspot.classfile.ClassLoaderData.classesDo(ClassLoaderData.java:107)
	at jdk.hotspot.agent/sun.jvm.hotspot.classfile.ClassLoaderDataGraph.classesDo(ClassLoaderDataGraph.java:84)
	at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.writeClasses(HeapHprofBinWriter.java:1137)
	at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.write(HeapHprofBinWriter.java:460)
	at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.writeHeapHprofBin(JMap.java:216)
	at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.run(JMap.java:103)
	at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
	at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
	at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
	at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.main(JMap.java:202)
	at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJMAP(SALauncher.java:340)
	at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:500)

java.io.EOFException
	at java.base/java.io.DataInputStream.readFully(DataInputStream.java:203)
	at java.base/java.io.DataInputStream.readFully(DataInputStream.java:172)
	at jdk.test.lib.hprof.parser.HprofReader.read(HprofReader.java:228)
	at jdk.test.lib.hprof.parser.Reader.readFile(Reader.java:95)
	at jdk.test.lib.hprof.HprofParser.parse(HprofParser.java:85)
	at jdk.test.lib.hprof.HprofParser.parse(HprofParser.java:54)
	at TestJmapCore.test(TestJmapCore.java:106)
	at TestJmapCore.main(TestJmapCore.java:70)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
	at java.base/java.lang.Thread.run(Thread.java:833)

JavaTest Message: Test threw exception: java.io.EOFException
JavaTest Message: shutting down test

result: Failed. Execution failed: `main' threw exception: java.io.EOFException

The test task's JVM args are: -XX:+CreateCoredumpOnCrash -XX:+UseZGC
Comments
A few comments back Dan said: -------- ProblemList-zgc.txt's entry for 8270202 does not include macosx-x64. However, ProblemList.txt does include this entry: test/hotspot/jtreg/ProblemList.txt:serviceability/sa/TestJmapCore.java 8267433 macosx-x64 so why did this test execute? --------- However, the failure he had just posted and was commenting on was a windows-x64 failure, and windows-x64 is not in the ProblemList-zgc.txt problem list: serviceability/sa/TestJmapCore.java 8268283,8270202 linux-aarch64,linux-x64,macosx-aarch64 So I incorrectly concluded that the problem list was not doing its job when in fact the problem list wasn't complete. There are in fact no macosx-x64 failures mentioned in this CR, likely because it is already problem listed on macosx-x64 for all runs. windows-x64 needs to be added to the zgc problem list for this test, and probably it should just be generic-all because I'm sure macosx-x64 would start failing if it was ever run. We wouldn't want it to suddenly start running and failing with zgc if it got removed from the main problem list due to JDK-8267433 being fixed.
06-03-2024

> so why did this test execute? [~dcubed] I believe the answer is because if the test is listed in two different problem lists, only one of the entries is used. The ProblemList-zgc.txt entry is ignored because it already exists in ProblemList.txt entry, and there it is only excluded on macosx-x64. I ran into this general issue years ago. I assume it has not been fixed yet in jtreg.
05-03-2024

[~cjplummer] - Filed: JDK-8318754 [macosx-aarch64] serviceability/sa/TestJmapCore.java still fails with "sun.jvm.hotspot.debugger.UnmappedAddressException: 801000800" and relinked the failure to the new bug.
24-10-2023

[~dcubed] What you are seeing is JDK-8314550, which I attempted to fix, but apparently the fix has failed. So I think a new CR would be best.
24-10-2023

$ grep serviceability/sa/TestJmapCore.java test/hotspot/jtreg/ProblemList* test/hotspot/jtreg/ProblemList-generational-zgc.txt:serviceability/sa/TestJmapCore.java 8307393 generic-all test/hotspot/jtreg/ProblemList-zgc.txt:serviceability/sa/TestJmapCore.java 8268283,8270202 linux-aarch64,linux-x64,macosx-aarch64 test/hotspot/jtreg/ProblemList.txt:serviceability/sa/TestJmapCore.java 8267433 macosx-x64 ProblemList-zgc.txt's entry for 8270202 does not include macosx-x64. However, ProblemList.txt does include this entry: test/hotspot/jtreg/ProblemList.txt:serviceability/sa/TestJmapCore.java 8267433 macosx-x64 so why did this test execute? Update: According to the task's stdout log: [2023-10-15T05:02:54,863Z] Executing: [( bash /cygdrive/c/ade/mesos/work_dir/jib-master/install/jdk-22+20-1523/src.full/open/make/scripts/fixpath.sh exec /cygdrive/c/ade/mesos/work_dir/jib-master/install/jdk/21/35/bundles/windows-x64/jdk-21_windows-x64_bin.zip/jdk-21/bin/java -Djava.library.path="/cygdrive/c/ade/mesos/work_dir/jib-master/install/jdk-22+20-1523/windows-x64-debug.test/failure_handler" -Dprogram=jtreg -jar /cygdrive/c/ade/mesos/work_dir/jib-master/install/jtreg/7.3.1/1/bundles/jtreg-7.3.1+1.zip/jtreg/lib/jtreg.jar -testThreadFactoryPath:/cygdrive/c/ade/mesos/work_dir/jib-master/install/jdk-22+20-1523/windows-x64-debug.test/jtreg_test_thread_factory/jtregTestThreadFactory.jar -testThreadFactory:Virtual -exclude:/cygdrive/c/ade/mesos/work_dir/jib-master/install/jdk-22+20-1523/src.full/open/test/hotspot/jtreg/ProblemList-Virtual.txt -agentvm -verbose:fail,error,time -retain:fail,error -concurrency:6 -timeoutFactor:4 -vmoption:-XX:MaxRAMPercentage=4.16667 -vmoption:-Dtest.boot.jdk="/cygdrive/c/ade/mesos/work_dir/jib-master/install/jdk/21/35/bundles/windows-x64/jdk-21_windows-x64_bin.zip/jdk-21" -vmoption:-Djava.io.tmpdir="/cygdrive/c/sb/prod/1697346154/testoutput/test-support/jtreg_open_test_hotspot_jtreg_serviceability_ttf_virtual/tmp" -automatic -ignore:quiet -e:JIB_DATA_DIR -e:_NT_SYMBOL_PATH -vmoption:-XX:+CreateCoredumpOnCrash -javaoption:-Duse.JTREG_TEST_THREAD_FACTORY=Virtual -javaoption:-XX:+UseZGC -javaoption:-XX:-VerifyContinuations -nativepath:/cygdrive/c/ade/mesos/work_dir/jib-master/install/jdk-22+20-1523/windows-x64-debug.test/hotspot/jtreg/native -exclude:/cygdrive/c/ade/mesos/work_dir/jib-master/install/jdk-22+20-1523/src.full/open/test/hotspot/jtreg/ProblemList.txt -exclude:/cygdrive/c/ade/mesos/work_dir/jib-master/install/jdk-22+20-1523/src.full/open/test/hotspot/jtreg/ProblemList-zgc.txt -e:JIB_HOME=/cygdrive/c/ade/mesos/work_dir/jib-master/install/com/oracle/java/jib/jib/3.0-SNAPSHOT/jib-3.0-20230929.141434-513-distribution.zip/jib-3.0-SNAPSHOT-distribution -e:TEST_IMAGE_DIR=/cygdrive/c/ade/mesos/work_dir/jib-master/install/jdk-22+20-1523/windows-x64-debug.test -k:'!headful' -testjdk:/cygdrive/c/ade/mesos/work_dir/jib-master/install/jdk-22+20-1523/windows-x64-debug.jdk/jdk-22/fastdebug -dir:/cygdrive/c/ade/mesos/work_dir/jib-master/install/jdk-22+20-1523/src.full -reportDir:/cygdrive/c/sb/prod/1697346154/testoutput/test-results/jtreg_open_test_hotspot_jtreg_serviceability_ttf_virtual -workDir:/cygdrive/c/sb/prod/1697346154/testoutput/test-support/jtreg_open_test_hotspot_jtreg_serviceability_ttf_virtual -report:files ${JTREG_STATUS} -timeoutHandlerDir:/cygdrive/c/ade/mesos/work_dir/jib-master/install/jdk-22+20-1523/windows-x64-debug.test/failure_handler/jtregFailureHandler.jar -observerDir:/cygdrive/c/ade/mesos/work_dir/jib-master/install/jdk-22+20-1523/windows-x64-debug.test/failure_handler/jtregFailureHandler.jar -timeoutHandler:jdk.test.failurehandler.jtreg.GatherProcessInfoTimeoutHandler -observer:jdk.test.failurehandler.jtreg.GatherDiagnosticInfoObserver -timeoutHandlerTimeout:0 open/test/hotspot/jtreg:serviceability_ttf_virtual && echo $? > /cygdrive/c/sb/prod/1697346154/testoutput/test-results/jtreg_open_test_hotspot_jtreg_serviceability_ttf_virtual/exitcode.txt || echo $? > /cygdrive/c/sb/prod/1697346154/testoutput/test-results/jtreg_open_test_hotspot_jtreg_serviceability_ttf_virtual/exitcode.txt )] We have a total of three ProblemLists in play here: -exclude:/cygdrive/c/ade/mesos/work_dir/jib-master/install/jdk-22+20-1523/src.full/open/test/hotspot/jtreg/ProblemList-Virtual.txt -exclude:/cygdrive/c/ade/mesos/work_dir/jib-master/install/jdk-22+20-1523/src.full/open/test/hotspot/jtreg/ProblemList.txt -exclude:/cygdrive/c/ade/mesos/work_dir/jib-master/install/jdk-22+20-1523/src.full/open/test/hotspot/jtreg/ProblemList-zgc.txt
15-10-2023

I filed JDK-8314550 for the issue on macosx-aarch64. If you see the following: sun.jvm.hotspot.debugger.UnmappedAddressException: 7001000800 And the hs_err file shows that address to be in the CDS archive: CDS archive(s) mapped at: [0x0000007000000000-0x0000007000d28000-0x0000007000d28000) Then please enter the failure in JDK-8314550. You'll will only ever see this happen with macosx-aarch64. This CR remains open for the originally reported ZGC failures that can happen on all platforms. The exception and stack trace look similar to JDK-8314550, but are for a different reason (address is not in the CDS archive). Since the test is now problem listed for ZGC due to this CR, I don't expect to see any new occurrences of this CR.
17-08-2023

Here's a log file snippet from the jdk-22+11-768-tier2 sighting: serviceability/sa/TestJmapCore.java #section:driver ----------messages:(7/248)---------- command: driver TestJmapCore run heap reason: User specified action: run driver/timeout=480 TestJmapCore run heap started: Tue Aug 15 11:26:52 GMT 2023 Mode: agentvm Agent id: 8 finished: Tue Aug 15 11:27:01 GMT 2023 elapsed time (seconds): 8.812 ----------configuration:(14/2022)---------- <snip> ----------System.out:(34/4678)---------- Command line: [/System/Volumes/Data/mesos/work_dir/jib-master/install/jdk-22+11-768/macosx-aarch64-debug.jdk/jdk-22/fastdebug/bin/java -cp /System/Volumes/Data/mesos/work_dir/slaves/cd627e65-f015-4fb1-a1d2-b6c9b8127f98-S135545/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/80df00f9-6e14-4650-8090-52eaf82b3109/runs/d97f11ba-fc3e-4daa-9290-1634276212df/testoutput/test-support/jtreg_open_test_hotspot_jtreg_hotspot_tier2_serviceability/classes/3/serviceability/sa/TestJmapCore.d:/System/Volumes/Data/mesos/work_dir/jib-master/install/jdk-22+11-768/src.full/open/test/hotspot/jtreg/serviceability/sa:/System/Volumes/Data/mesos/work_dir/slaves/cd627e65-f015-4fb1-a1d2-b6c9b8127f98-S135545/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/80df00f9-6e14-4650-8090-52eaf82b3109/runs/d97f11ba-fc3e-4daa-9290-1634276212df/testoutput/test-support/jtreg_open_test_hotspot_jtreg_hotspot_tier2_serviceability/classes/3/test/lib:/System/Volumes/Data/mesos/work_dir/jib-master/install/jtreg/7.3/1/bundles/jtreg-7.3+1.zip/jtreg/lib/jtreg.jar:/System/Volumes/Data/mesos/work_dir/jib-master/install/jtreg/7.3/1/bundles/jtreg-7.3+1.zip/jtreg/lib/junit-platform-console-standalone-1.9.2.jar:/System/Volumes/Data/mesos/work_dir/jib-master/install/jtreg/7.3/1/bundles/jtreg-7.3+1.zip/jtreg/lib/testng-7.3.0.jar:/System/Volumes/Data/mesos/work_dir/jib-master/install/jtreg/7.3/1/bundles/jtreg-7.3+1.zip/jtreg/lib/jcommander-1.82.jar:/System/Volumes/Data/mesos/work_dir/jib-master/install/jtreg/7.3/1/bundles/jtreg-7.3+1.zip/jtreg/lib/guice-5.1.0.jar -XX:MaxRAMPercentage=6.25 -Dtest.boot.jdk=/System/Volumes/Data/mesos/work_dir/jib-master/install/jdk/20/36/bundles/macos-aarch64/jdk-20_macos-aarch64_bin.tar.gz/jdk-20.jdk/Contents/Home -Djava.io.tmpdir=/System/Volumes/Data/mesos/work_dir/slaves/cd627e65-f015-4fb1-a1d2-b6c9b8127f98-S135545/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/80df00f9-6e14-4650-8090-52eaf82b3109/runs/d97f11ba-fc3e-4daa-9290-1634276212df/testoutput/test-support/jtreg_open_test_hotspot_jtreg_hotspot_tier2_serviceability/tmp -XX:+CreateCoredumpOnCrash -Xmx512m -XX:MaxMetaspaceSize=64m -XX:+CrashOnOutOfMemoryError -XX:+AlwaysPreTouch TestJmapCore heap ] [2023-08-15T11:26:53.032362Z] Gathering output for process 59919 [2023-08-15T11:26:53.036880Z] Waiting for completion for process 59919 [2023-08-15T11:26:53.037189Z] Waiting for completion finished for process 59919 Output and diagnostic info for process 59919 was saved into 'pid-59919-output.log' [2023-08-15T11:26:53.041281Z] Waiting for completion for process 59919 [2023-08-15T11:26:53.041375Z] Waiting for completion finished for process 59919 Run test with ulimit -c: unlimited [2023-08-15T11:26:53.044603Z] Gathering output for process 59920 [2023-08-15T11:27:01.200409Z] Waiting for completion for process 59920 [2023-08-15T11:27:01.200605Z] Waiting for completion finished for process 59920 Output and diagnostic info for process 59920 was saved into 'pid-59920-output.log' crashOutputString = [Aborting due to java.lang.OutOfMemoryError: Java heap space # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/System/Volumes/Data/mesos/work_dir/slaves/cd627e65-f015-4fb1-a1d2-b6c9b8127f98-S127034/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/30c5d7a0-c6b8-42eb-853f-9c3f54966c2b/runs/00dc98d3-0540-432d-9151-55f6ca4f253a/workspace/open/src/hotspot/share/utilities/debug.cpp:271), pid=59921, tid=10243 # fatal error: OutOfMemory encountered: Java heap space # # JRE version: Java(TM) SE Runtime Environment (22.0+11) (fastdebug build 22-ea+11-768) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 22-ea+11-768, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-aarch64) # Core dump will be written. Default location: core.59921 # # An error report file with more information is saved as: # /System/Volumes/Data/mesos/work_dir/slaves/cd627e65-f015-4fb1-a1d2-b6c9b8127f98-S135545/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/80df00f9-6e14-4650-8090-52eaf82b3109/runs/d97f11ba-fc3e-4daa-9290-1634276212df/testoutput/test-support/jtreg_open_test_hotspot_jtreg_hotspot_tier2_serviceability/scratch/1/hs_err_pid59921.log ] getCoreFileLocation found stringWithLocation = core.59921 Found core file core.59921, size = 4315mb [2023-08-15T11:27:01.221649Z] Gathering output for process 59951 Attaching to core core.59921 from executable /System/Volumes/Data/mesos/work_dir/jib-master/install/jdk-22+11-768/macosx-aarch64-debug.jdk/jdk-22/fastdebug/bin/java, please wait... Debugger attached successfully. Server compiler detected. JVM version is 22-ea+11-768 ----------System.err:(42/3125)---------- sun.jvm.hotspot.debugger.UnmappedAddressException: 7001000800 at jdk.hotspot.agent/sun.jvm.hotspot.debugger.PageCache.checkPage(PageCache.java:208) at jdk.hotspot.agent/sun.jvm.hotspot.debugger.PageCache.getLong(PageCache.java:100) at jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readCInteger(DebuggerBase.java:356) at jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readAddressValue(DebuggerBase.java:382) at jdk.hotspot.agent/sun.jvm.hotspot.debugger.bsd.BsdDebuggerLocal.readAddress(BsdDebuggerLocal.java:421) at jdk.hotspot.agent/sun.jvm.hotspot.debugger.bsd.BsdAddress.getAddressAt(BsdAddress.java:73) at jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicTypeDataBase.findDynamicTypeForAddress(BasicTypeDataBase.java:238) at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualBaseConstructor.instantiateWrapperFor(VirtualBaseConstructor.java:104) at jdk.hotspot.agent/sun.jvm.hotspot.oops.Metadata.instantiateWrapperFor(Metadata.java:78) at jdk.hotspot.agent/sun.jvm.hotspot.oops.MetadataField.getValue(MetadataField.java:43) at jdk.hotspot.agent/sun.jvm.hotspot.oops.MetadataField.getValue(MetadataField.java:40) at jdk.hotspot.agent/sun.jvm.hotspot.classfile.ClassLoaderData.getKlasses(ClassLoaderData.java:82) at jdk.hotspot.agent/sun.jvm.hotspot.classfile.ClassLoaderData.classesDo(ClassLoaderData.java:101) at jdk.hotspot.agent/sun.jvm.hotspot.classfile.ClassLoaderDataGraph.classesDo(ClassLoaderDataGraph.java:84) at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.writeSymbols(HeapHprofBinWriter.java:1206) at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.write(HeapHprofBinWriter.java:454) at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.writeHeapHprofBin(JMap.java:216) at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.run(JMap.java:103) at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278) at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241) at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134) at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.main(JMap.java:202) at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJMAP(SALauncher.java:340) at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:500) java.io.EOFException at java.base/java.io.DataInputStream.readFully(DataInputStream.java:210) at java.base/java.io.DataInputStream.readInt(DataInputStream.java:385) at jdk.test.lib.hprof.parser.Reader.readFile(Reader.java:90) at jdk.test.lib.hprof.HprofParser.parse(HprofParser.java:85) at jdk.test.lib.hprof.HprofParser.parse(HprofParser.java:54) at TestJmapCore.test(TestJmapCore.java:107) at TestJmapCore.main(TestJmapCore.java:70) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:580) at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333) at java.base/java.lang.Thread.run(Thread.java:1570) JavaTest Message: Test threw exception: java.io.EOFException JavaTest Message: shutting down test result: Failed. Execution failed: `main' threw exception: java.io.EOFException
15-08-2023

[~dholmes] bumped the priority from P4 -> P3 when this failure started happening a lot with macosx-aarch64 with ZGC: https://bugs.openjdk.org/browse/JDK-8270202?focusedCommentId=14540479&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14540479 The test has since been ProblemListed in that config so I'm lowering the priority back to P4.
01-02-2023

I've been unable to reproduce the macos-aarch64 failures related to accessing the CDS archive, so I've been unable to verify Ioi's suggested change. One thing I did noticed is that JDK-8293563 (failure of the java heap to appear in the core file) started with 11.2.5 and continued with 11.4 before I fixed it with AlwaysPreTouch. Now we have a bunch of 12.x hosts, and I noticed that we've recorded about 10 of these macos-aarch64 failures, and all of them have been on 11.4 and 11.6.* hosts. I don't see any failures reported on 12.* hosts. Due to this I then narrowed my testing to just the 11.* hosts (which we don't have that many of now), but still couldn't get it to fail after 100's of runs.
15-12-2022

If specifying -XX:+AlwaysPreTouch is a viable work-around, this can be changed for CDS (metaspaceShared.cpp): static bool use_windows_memory_mapping() { const bool is_windows = (NOT_WINDOWS(false) WINDOWS_ONLY(true)); //const bool is_windows = true; // enable this to allow testing the windows mmap semantics on Linux, etc. - return is_windows; + return is_windows || AlwaysPreTouch } This will basically avoid using mmap on the CDS regions. Instead, we use read() to copy the contents into memory. Maybe this way, macosx-aarch64 will make these regions available in the core file.
05-12-2022

This latest failure is with G1, not ZGC. The point of this bug was mainly to address ZGC issues, which we know will happen given how ZGC works and SA not fully supporting it. It looks like even some of the older failures above are with G1. Since this test purposely generates a core file, I looked at the hs_err file which was also produced and saw this: garbage-first heap total 524288K, used 1070K [0x00000007e0000000, 0x0000000800000000) So 801000800 is not in the java heap. However, I also saw: CDS archive(s) mapped at: [0x0000000800000000-0x0000000800cf0000-0x0000000800cf0000), size 13565952, SharedBaseAddress: 0x0000000800000000, ArchiveRelocationMode: 0. Compressed class space mapped at: 0x0000000801000000-0x0000000804400000, reserved size: 54525952 Narrow klass base: 0x0000000800000000, Narrow klass shift: 0, Narrow klass range: 0x100000000 So 801000800 is in the CDS archive's "Compressed class space". When the SA page cache tries to read it in, it throws: sun.jvm.hotspot.debugger.UnmappedAddressException: 801000800 Our test tools also ran jstack on the core files and got SA exceptions like the following: sun.jvm.hotspot.debugger.UnmappedAddressException: 80001a3d8 sun.jvm.hotspot.debugger.UnmappedAddressException: 800048590 These appear to be in the CDS archive. My guess is that these addresses are valid but are not in the core file. See JDK-8293563, which documents issues with macosx-aarch64 not including all of (most of) the java heap in the core dump. Even lldb can't read these pages. This was fixed by using -XX:+AlwaysPreTouch. However, I doubt that helps with the mapped in CDS archive. We may need for CDS to access all pages in the archive when -XX:+AlwaysPreTouch is used ([~iklam]?)
05-12-2022

I'm not familiar of Mac, but can we set something like coredump_filter on Linux? (it seems to be difficult when I googled...)
28-11-2022

Yes sorry, all recent failure on macOS Aarch64.
28-11-2022

> We have now seen this fail about 6 times since November 10, so it seems something has changed recently. Does it mean the problem happens on Mac on AArch64?
28-11-2022

Bumping to P3. We have now seen this fail about 6 times since November 10, so it seems something has changed recently. ----------System.err:(41/3050)---------- sun.jvm.hotspot.debugger.UnmappedAddressException: 801000800 at jdk.hotspot.agent/sun.jvm.hotspot.debugger.PageCache.checkPage(PageCache.java:208) at jdk.hotspot.agent/sun.jvm.hotspot.debugger.PageCache.getLong(PageCache.java:100) at jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readCInteger(DebuggerBase.java:356) at jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readAddressValue(DebuggerBase.java:382) at jdk.hotspot.agent/sun.jvm.hotspot.debugger.bsd.BsdDebuggerLocal.readAddress(BsdDebuggerLocal.java:421) at jdk.hotspot.agent/sun.jvm.hotspot.debugger.bsd.BsdAddress.getAddressAt(BsdAddress.java:73) at jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicTypeDataBase.findDynamicTypeForAddress(BasicTypeDataBase.java:238) at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualBaseConstructor.instantiateWrapperFor(VirtualBaseConstructor.java:104) at jdk.hotspot.agent/sun.jvm.hotspot.oops.Metadata.instantiateWrapperFor(Metadata.java:77) at jdk.hotspot.agent/sun.jvm.hotspot.oops.MetadataField.getValue(MetadataField.java:43) at jdk.hotspot.agent/sun.jvm.hotspot.oops.MetadataField.getValue(MetadataField.java:40) at jdk.hotspot.agent/sun.jvm.hotspot.classfile.ClassLoaderData.getKlasses(ClassLoaderData.java:82) at jdk.hotspot.agent/sun.jvm.hotspot.classfile.ClassLoaderData.classesDo(ClassLoaderData.java:101) at jdk.hotspot.agent/sun.jvm.hotspot.classfile.ClassLoaderDataGraph.classesDo(ClassLoaderDataGraph.java:84) at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.writeSymbols(HeapHprofBinWriter.java:1207) at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.write(HeapHprofBinWriter.java:455) at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.writeHeapHprofBin(JMap.java:216) at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.run(JMap.java:103) at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278) at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241) at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134) at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.main(JMap.java:202) at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJMAP(SALauncher.java:340) at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:500) java.io.EOFException at java.base/java.io.DataInputStream.readInt(DataInputStream.java:386) at jdk.test.lib.hprof.parser.Reader.readFile(Reader.java:90) at jdk.test.lib.hprof.HprofParser.parse(HprofParser.java:85) at jdk.test.lib.hprof.HprofParser.parse(HprofParser.java:54) at TestJmapCore.test(TestJmapCore.java:107) at TestJmapCore.main(TestJmapCore.java:70) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:578) at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312) at java.base/java.lang.Thread.run(Thread.java:1591)
27-11-2022

Here's a log file snippet from jdk-20+24-1747-tier2 sighting: serviceability/sa/TestJmapCore.java ----------System.err:(41/3050)---------- sun.jvm.hotspot.debugger.UnmappedAddressException: 801000800 at jdk.hotspot.agent/sun.jvm.hotspot.debugger.PageCache.checkPage(PageCache.java:208) at jdk.hotspot.agent/sun.jvm.hotspot.debugger.PageCache.getLong(PageCache.java:100) at jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readCInteger(DebuggerBase.java:356) at jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readAddressValue(DebuggerBase.java:382) at jdk.hotspot.agent/sun.jvm.hotspot.debugger.bsd.BsdDebuggerLocal.readAddress(BsdDebuggerLocal.java:421) at jdk.hotspot.agent/sun.jvm.hotspot.debugger.bsd.BsdAddress.getAddressAt(BsdAddress.java:73) at jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicTypeDataBase.findDynamicTypeForAddress(BasicTypeDataBase.java:238) at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualBaseConstructor.instantiateWrapperFor(VirtualBaseConstructor.java:104) at jdk.hotspot.agent/sun.jvm.hotspot.oops.Metadata.instantiateWrapperFor(Metadata.java:77) at jdk.hotspot.agent/sun.jvm.hotspot.oops.MetadataField.getValue(MetadataField.java:43) at jdk.hotspot.agent/sun.jvm.hotspot.oops.MetadataField.getValue(MetadataField.java:40) at jdk.hotspot.agent/sun.jvm.hotspot.classfile.ClassLoaderData.getKlasses(ClassLoaderData.java:82) at jdk.hotspot.agent/sun.jvm.hotspot.classfile.ClassLoaderData.classesDo(ClassLoaderData.java:101) at jdk.hotspot.agent/sun.jvm.hotspot.classfile.ClassLoaderDataGraph.classesDo(ClassLoaderDataGraph.java:84) at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.writeSymbols(HeapHprofBinWriter.java:1207) at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.write(HeapHprofBinWriter.java:455) at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.writeHeapHprofBin(JMap.java:216) at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.run(JMap.java:103) at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278) at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241) at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134) at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.main(JMap.java:202) at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJMAP(SALauncher.java:340) at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:500) java.io.EOFException at java.base/java.io.DataInputStream.readInt(DataInputStream.java:386) at jdk.test.lib.hprof.parser.Reader.readFile(Reader.java:90) at jdk.test.lib.hprof.HprofParser.parse(HprofParser.java:85) at jdk.test.lib.hprof.HprofParser.parse(HprofParser.java:54) at TestJmapCore.test(TestJmapCore.java:107) at TestJmapCore.main(TestJmapCore.java:70) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:578) at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312) at java.base/java.lang.Thread.run(Thread.java:1591) JavaTest Message: Test threw exception: java.io.EOFException JavaTest Message: shutting down test result: Failed. Execution failed: `main' threw exception: java.io.EOFException In addition to the UnmappedAddressException, the test also failed due to "java.lang.OutOfMemoryError: Java heap space" Output and diagnostic info for process 72731 was saved into 'pid-72731-output.log' crashOutputString = [Aborting due to java.lang.OutOfMemoryError: Java heap space # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/debug.cpp:368 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/System/Volumes/Data/mesos/work_dir/slaves/0c72054a-24ab-4dbb-944f-97f9341a1b96-S79655/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/d6c1d48f-551e-4767-bcb5-2973539af23a/runs/1fd578ba-1709-4a19-9813-66fd9fb5b75c/workspace/open/src/hotspot/share/utilities/debug.cpp:368), pid=72732, tid=10243 # fatal error: OutOfMemory encountered: Java heap space # # JRE version: Java(TM) SE Runtime Environment (20.0+24) (fastdebug build 20-ea+24-1747) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 20-ea+24-1747, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-aarch64) # Core dump will be written. Default location: core.72732 # # An error report file with more information is saved as: # /System/Volumes/Data/mesos/work_dir/slaves/0c72054a-24ab-4dbb-944f-97f9341a1b96-S148728/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/abb4f312-d29b-417b-bcab-78d0999bd5c5/runs/12bce60a-29ff-4cfd-829b-b8e0ecb5afaa/testoutput/test-support/jtreg_open_test_hotspot_jtreg_hotspot_tier2_serviceability/scratch/0/hs_err_pid72732.log ] I know the test intentionally causes a crash so that it can examine a core file, but I didn't think the crash was an OOM... Here's the crashing thread's stack: --------------- T H R E A D --------------- Current thread (0x0000000126008210): JavaThread "main" [_thread_in_vm, id=10243, stack(0x000000016dca4000,0x000000016dea7000)] Stack: [0x000000016dca4000,0x000000016dea7000], sp=0x000000016dea67f0, free space=2057k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.dylib+0x10a3fa4] VMError::report_and_die(int, char const*, char const*, char*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x5c8 (debug.cpp:368) V [libjvm.dylib+0x573688] report_fatal(VMErrorType, char const*, int, char const*, ...)+0xa4 V [libjvm.dylib+0x573984] report_java_out_of_memory(char const*)+0xd8 V [libjvm.dylib+0xcc72fc] MemAllocator::Allocation::check_out_of_memory()+0x100 V [libjvm.dylib+0xcc8794] MemAllocator::allocate() const+0x1a0 V [libjvm.dylib+0x4d2788] CollectedHeap::array_allocate(Klass*, unsigned long, int, bool, JavaThread*)+0x30 V [libjvm.dylib+0x83ef74] InstanceKlass::allocate_objArray(int, int, JavaThread*)+0xd8 V [libjvm.dylib+0x867058] InterpreterRuntime::anewarray(JavaThread*, ConstantPool*, int, int)+0x1fc j TestJmapCore.main([Ljava/lang/String;)V+19 v ~StubRoutines::call_stub 0x000000011769017c V [libjvm.dylib+0x87d6c8] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x4cc V [libjvm.dylib+0x95a56c] jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, JavaThread*)+0x1b8 V [libjvm.dylib+0x95eecc] jni_CallStaticVoidMethod+0x138 C [libjli.dylib+0x71fc] JavaMain+0x9bc C [libjli.dylib+0x94ec] ThreadJavaMain+0xc C [libsystem_pthread.dylib+0x7878] _pthread_start+0x140 Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j TestJmapCore.main([Ljava/lang/String;)V+19 v ~StubRoutines::call_stub 0x000000011769017c
15-11-2022

Here's a log file snippet from the jdk-20+23-1663-tier2 sighting: serviceability/sa/TestJmapCore.java ----------System.err:(41/3050)---------- sun.jvm.hotspot.debugger.UnmappedAddressException: 801000800 at jdk.hotspot.agent/sun.jvm.hotspot.debugger.PageCache.checkPage(PageCache.java:208) at jdk.hotspot.agent/sun.jvm.hotspot.debugger.PageCache.getLong(PageCache.java:100) at jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readCInteger(DebuggerBase.java:356) at jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readAddressValue(DebuggerBase.java:382) at jdk.hotspot.agent/sun.jvm.hotspot.debugger.bsd.BsdDebuggerLocal.readAddress(BsdDebuggerLocal.java:421) at jdk.hotspot.agent/sun.jvm.hotspot.debugger.bsd.BsdAddress.getAddressAt(BsdAddress.java:73) at jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicTypeDataBase.findDynamicTypeForAddress(BasicTypeDataBase.java:238) at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualBaseConstructor.instantiateWrapperFor(VirtualBaseConstructor.java:104) at jdk.hotspot.agent/sun.jvm.hotspot.oops.Metadata.instantiateWrapperFor(Metadata.java:77) at jdk.hotspot.agent/sun.jvm.hotspot.oops.MetadataField.getValue(MetadataField.java:43) at jdk.hotspot.agent/sun.jvm.hotspot.oops.MetadataField.getValue(MetadataField.java:40) at jdk.hotspot.agent/sun.jvm.hotspot.classfile.ClassLoaderData.getKlasses(ClassLoaderData.java:82) at jdk.hotspot.agent/sun.jvm.hotspot.classfile.ClassLoaderData.classesDo(ClassLoaderData.java:101) at jdk.hotspot.agent/sun.jvm.hotspot.classfile.ClassLoaderDataGraph.classesDo(ClassLoaderDataGraph.java:84) at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.writeSymbols(HeapHprofBinWriter.java:1207) at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.write(HeapHprofBinWriter.java:455) at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.writeHeapHprofBin(JMap.java:216) at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.run(JMap.java:103) at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278) at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241) at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134) at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.main(JMap.java:202) at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJMAP(SALauncher.java:340) at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:500) java.io.EOFException at java.base/java.io.DataInputStream.readInt(DataInputStream.java:386) at jdk.test.lib.hprof.parser.Reader.readFile(Reader.java:90) at jdk.test.lib.hprof.HprofParser.parse(HprofParser.java:85) at jdk.test.lib.hprof.HprofParser.parse(HprofParser.java:54) at TestJmapCore.test(TestJmapCore.java:107) at TestJmapCore.main(TestJmapCore.java:70) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:578) at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312) at java.base/java.lang.Thread.run(Thread.java:1591) JavaTest Message: Test threw exception: java.io.EOFException JavaTest Message: shutting down test result: Failed. Execution failed: `main' threw exception: java.io.EOFException
09-11-2022

Same issue seen on macos-Aarch64 with G1 ----------System.err:(42/3153)---------- sun.jvm.hotspot.debugger.UnmappedAddressException: 800c00800 at jdk.hotspot.agent/sun.jvm.hotspot.debugger.PageCache.checkPage(PageCache.java:208) at jdk.hotspot.agent/sun.jvm.hotspot.debugger.PageCache.getData(PageCache.java:63) at jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readBytes(DebuggerBase.java:225) at jdk.hotspot.agent/sun.jvm.hotspot.debugger.bsd.BsdDebuggerLocal.readCInteger(BsdDebuggerLocal.java:508) at jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readAddressValue(DebuggerBase.java:462) at jdk.hotspot.agent/sun.jvm.hotspot.debugger.bsd.BsdDebuggerLocal.readAddress(BsdDebuggerLocal.java:443) at jdk.hotspot.agent/sun.jvm.hotspot.debugger.bsd.BsdAddress.getAddressAt(BsdAddress.java:73) at jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicTypeDataBase.findDynamicTypeForAddress(BasicTypeDataBase.java:241) at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualBaseConstructor.instantiateWrapperFor(VirtualBaseConstructor.java:104) at jdk.hotspot.agent/sun.jvm.hotspot.oops.Metadata.instantiateWrapperFor(Metadata.java:76) at jdk.hotspot.agent/sun.jvm.hotspot.oops.MetadataField.getValue(MetadataField.java:43) at jdk.hotspot.agent/sun.jvm.hotspot.oops.MetadataField.getValue(MetadataField.java:40) at jdk.hotspot.agent/sun.jvm.hotspot.classfile.ClassLoaderData.getKlasses(ClassLoaderData.java:82) at jdk.hotspot.agent/sun.jvm.hotspot.classfile.ClassLoaderData.classesDo(ClassLoaderData.java:101) at jdk.hotspot.agent/sun.jvm.hotspot.classfile.ClassLoaderDataGraph.classesDo(ClassLoaderDataGraph.java:84) at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.writeSymbols(HeapHprofBinWriter.java:1207) at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.write(HeapHprofBinWriter.java:455) at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.writeHeapHprofBin(JMap.java:216) at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.run(JMap.java:103) at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278) at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241) at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134) at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.main(JMap.java:202) at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJMAP(SALauncher.java:340) at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:500)
25-11-2021

Ok, I will add this to ProblemList in JDK 18.
04-08-2021

[~ysuenaga] I think you can problem list this test now on Linux x64.
03-08-2021

Actually maybe it doesn't need to be problem listed, at least not yet. This is the only failure so far, so it's not creating noise in our testing.
10-07-2021

I think this issue should also be problem-listed in JDK 17 because SA code for ZGC is not so different from JDK 18. Can I send PR for JDK 17? I want to know the condition for the reproduce. I think we've not yet understood essence of the problem. I've not yet reproduced issues on my Linux x64. I think we should know the details of the problem and ZGC more to fix.
10-07-2021

More than likely this is ZGC related and not related to JDK-8269982. Probably the same issue as JDK-8268636 or JDK-8268283, which themselves appear to be dups of each other. We already have done some ZGC problem listing for them: serviceability/sa/TestJmapCore.java 8268722,8268283 macosx-x64,linux-aarch64 serviceability/sa/TestJmapCoreMetaspace.java 8268722,8268636 generic-all We should probably change TestJmapCore.java to be problem listed on all platforms.
09-07-2021

Similar to this one on macos-aarch64, but I've only seen this failure with this test on linux-x64 once: JDK-8269982 [macos-aarch64] SA tests failing with UnmappedAddressException
09-07-2021