JDK-8253079 : DeterministicDump.java fails due to garbage in structure padding
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 16
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2020-09-14
  • Updated: 2020-09-29
  • Resolved: 2020-09-22
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 16
16 b17Fixed
Related Reports
Relates :  
JDK-8244778 - Archive full module graph in CDS
Description
[2020-09-13T23:29:13.086022Z] Waiting for completion for process 33700
[2020-09-13T23:29:13.086094Z] Waiting for completion finished for process 33700
Command line: [/Users/fool/workspace/git/github/DamonFool/jdk/build/macosx-x86_64-server-release/images/jdk/bin/java -cp /Users/fool/workspace/git/github/DamonFool/jdk/build/macosx-x86_64-server-release/test-support/jtreg_test_hotspot_jtreg_runtime_cds_DeterministicDump_java/classes/0/runtime/cds/DeterministicDump.d:/Users/fool/workspace/git/github/DamonFool/jdk/test/hotspot/jtreg/runtime/cds:/Users/fool/workspace/git/github/DamonFool/jdk/build/macosx-x86_64-server-release/test-support/jtreg_test_hotspot_jtreg_runtime_cds_DeterministicDump_java/classes/0/test/lib:/Users/fool/workspace/open/jtreg/lib/javatest.jar:/Users/fool/workspace/open/jtreg/lib/jtreg.jar:/Users/fool/workspace/open/jtreg/lib/junit.jar:/Users/fool/workspace/open/jtreg/lib/testng.jar:/Users/fool/workspace/open/jtreg/lib/jcommander.jar -Xmx128M -XX:+UseCompressedOops -XX:+UseCompressedClassPointers -XX:SharedArchiveFile=SharedArchiveFile4.jsa -Xshare:dump -Xlog:cds=debug ]
[2020-09-13T23:29:13.088680Z] Gathering output for process 33701
[ELAPSED: 428 ms]
[logging stdout to /Users/fool/workspace/git/github/DamonFool/jdk/build/macosx-x86_64-server-release/test-support/jtreg_test_hotspot_jtreg_runtime_cds_DeterministicDump_java/scratch/0/runtime.cds.DeterministicDump.java-0004-SharedArchiveFile4.stdout]
[logging stderr to /Users/fool/workspace/git/github/DamonFool/jdk/build/macosx-x86_64-server-release/test-support/jtreg_test_hotspot_jtreg_runtime_cds_DeterministicDump_java/scratch/0/runtime.cds.DeterministicDump.java-0004-SharedArchiveFile4.stderr]
[STDERR]

[2020-09-13T23:29:13.514175Z] Waiting for completion for process 33701
[2020-09-13T23:29:13.514368Z] Waiting for completion finished for process 33701
STDERR:
java.lang.RuntimeException: File content different at byte #4, b0 = 115, b1 = 120
        at DeterministicDump.compare(DeterministicDump.java:117)
        at DeterministicDump.doTest(DeterministicDump.java:68)
        at DeterministicDump.main(DeterministicDump.java:47)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:564)
        at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298)
        at java.base/java.lang.Thread.run(Thread.java:832)

JavaTest Message: Test threw exception: java.lang.RuntimeException
JavaTest Message: shutting down tes
Comments
Changeset: 284bbf02 Author: Ioi Lam <iklam@openjdk.org> Date: 2020-09-22 08:04:26 +0000 URL: https://git.openjdk.java.net/jdk/commit/284bbf02
22-09-2020
[~jwilhelm] a PR is in-flight. Should be integrated soon.
21-09-2020
Here are the logs from my sightings in my jdk-16+16 stress runs: $ unzip -l jdk-16+16_linux.8253079.zip Archive: jdk-16+16_linux.8253079.zip Length Date Time Name --------- ---------- ----- ---- 23164 2020-09-18 13:24 jdk-16+16_1/failures.linux-x86_64/DeterministicDump.jtr.release 23167 2020-09-19 19:56 jdk-16+16_2/failures.linux-x86_64/DeterministicDump.jtr.release 23165 2020-09-21 03:49 jdk-16+16_3/failures.linux-x86_64/DeterministicDump.jtr.release --------- ------- 69496 3 files
21-09-2020
This test has been failing in every single tier 6 run last week. Why wasn't is problemlisted?
21-09-2020
WIP: https://github.com/iklam/jdk/tree/8253079-DeterministicDump-test-fails-product-build In product builds (-O3 without -g), gcc on x64 stores garbage into the structure padding slot behind BasicHashtableEntry::_hash in BasicHashtable<F>::new_entry(). The garbage value turns out to be the upper bits of a Symbol*, which are different on every run of "java -Xshare:dump". The fix is to avoid copying contents of the structure padding slots when copying PackageEntry and ModuleEntry objects into the archive.
19-09-2020
I can reproduce the failure in a product VM (Oracle build). The failure also happen on Oracle CI tier 6 (OpenJDK build, product VM). So it looks like the failure happens only on product VMs. It doesn't matter whether you're using a Oracle or OpenJDK build. [~dcubed] JDK-8253261 only disables the *use* of the archived module graph. It doesn't affect the content of the archive (which still contains the module graph). I'll build a product VM with debugging into and analyze per: https://wiki.openjdk.java.net/display/HotSpot/Debugging+CDS+DeterministicDump.java+test+failures
19-09-2020
My local test on runtime/cds/DeterministicDump.java linux ubuntu (git log): 03a4df0acd1 8244778: Archive full module graph in CDS // fail 998ce78e530 8252543: [JVMCI] Libgraal can deadlock in blocking compilation mode //pass The failure showed: File content different at byte #4, b0 = -57, b1 = -25 which is _crc field in FileMapHeader. Even after disable full module graph, it still failed.
18-09-2020
The fix for the following was pushed in jdk-16+16-714: JDK-8253261 Disable CDS full module graph until JDK-8253081 is fixed so I was expecting this failure mode to stop happening, but it still happens in the JDK16 CI.
18-09-2020
[~dholmes] yes, but that was when I had a bug in the code, which I fixed in https://github.com/iklam/jdk/commit/97706f58b9c17ddb9e109ae8661fe5cf9649fb7e before integrating.
17-09-2020
For some reasons this happens only with openjdk build, but not with Oracle JDK build.
17-09-2020
ILW = HLM = P3
15-09-2020