JDK-8244536 : cds/DeterministicDump.java failed: File content different
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 15
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows
  • CPU: x86_64
  • Submitted: 2020-05-06
  • Updated: 2023-08-03
  • Resolved: 2020-05-18
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 15
15 b24Fixed
Related Reports
Relates :  
JDK-8245650 - cds/DeterministicDump.java still fails after JDK-8244536
Relates :  
JDK-8241071 - Generation of classes.jsa with -Xshare:dump is not deterministic
Sub Tasks
JDK-8244542 :  
ProblemList cds/DeterministicDump.java for Windows - Resolved
Description
The following test failed in the JDK15 CI:

runtime/cds/DeterministicDump.java

Here's a snippet from the log file:

----------System.err:(13/818)----------
java.lang.RuntimeException: File content different at byte #4, b0 = -52, b1 = 32
	at DeterministicDump.compare(DeterministicDump.java:93)
	at DeterministicDump.main(DeterministicDump.java:67)
	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 test

result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: File content different at byte #4, b0 = -52, b1 = 32
Comments
Hi [~iklam] - This test still fails in our Linux CI/CD. Could you please have a look at it? Thanks a lot.
18-05-2020
URL: https://hg.openjdk.java.net/jdk/jdk/rev/a95911422005 User: iklam Date: 2020-05-18 03:55:25 +0000
18-05-2020
ILW = MMM = P3
12-05-2020
There's also a different possible failure mode: if the archive needs to be relocated during dump time due to ASLR, the RW and BM sections are non-deterministic. This is likely to happen on Windows only, but can be simulated on Linux: $ java -XX:SharedArchiveFile=/tmp/ioi.jsa -Xshare:dump -Xlog:cds=debug | grep crc [1.146s][debug][cds] Shared file region (mc ) 0: 11112 bytes, addr 0x0000000800000000 file offset 0x00001000 crc 0x3ae8dbdb [1.151s][debug][cds] Shared file region (rw ) 1: 4071400 bytes, addr 0x0000000800003000 file offset 0x00004000 crc 0x36dc9700 [1.165s][debug][cds] Shared file region (ro ) 2: 7650168 bytes, addr 0x00000008003e5000 file offset 0x003e6000 crc 0xc29017a1 << [1.174s][debug][cds] Shared file region (bm ) 3: 209712 bytes, addr 0x0000000000000000 file offset 0x00b32000 crc 0x40072991 << [1.175s][debug][cds] Shared file region (ca0) 4: 507904 bytes, addr 0x00000007bf800000 file offset 0x00b66000 crc 0x7dffc85e [1.176s][debug][cds] Shared file region (oa0) 6: 335872 bytes, addr 0x00000007bf000000 file offset 0x00be2000 crc 0xb626c9d8 $ java -XX:SharedArchiveFile=/tmp/ioi.jsa -Xshare:dump -Xlog:cds=debug -XX:+UnlockDiagnosticVMOptions -XX:ArchiveRelocationMode=1 | grep crc [1.281s][debug][cds] Shared file region (mc ) 0: 11112 bytes, addr 0x0000000800000000 file offset 0x00001000 crc 0x3ae8dbdb [1.286s][debug][cds] Shared file region (rw ) 1: 4071400 bytes, addr 0x0000000800003000 file offset 0x00004000 crc 0x36dc9700 [1.300s][debug][cds] Shared file region (ro ) 2: 7650168 bytes, addr 0x00000008003e5000 file offset 0x003e6000 crc 0xb11cd6a2 << [1.308s][debug][cds] Shared file region (bm ) 3: 209712 bytes, addr 0x0000000000000000 file offset 0x00b32000 crc 0xa18495dd << [1.309s][debug][cds] Shared file region (ca0) 4: 507904 bytes, addr 0xffff80ef17800000 file offset 0x00b66000 crc 0x7dffc85e [1.310s][debug][cds] Shared file region (oa0) 6: 335872 bytes, addr 0xffff80ef17000000 file offset 0x00be2000 crc 0xb626c9d8
06-05-2020
There are only very minor differences between the two JSA files. See the attached stdout files. All crc of the mc/ro/rw/bm regions are identical. Only the header is different: $ hexdump SharedArchiveFile0.jsa > 0.txt $ hexdump SharedArchiveFile1.jsa > 1.txt $ diff 0.txt 1.txt < 0000000 aba2 f00b 48cc 340e 000a 0000 0000 0000 > 0000000 aba2 f00b 3420 49aa 000a 0000 0000 0000 < 0000260 0008 0000 0000 0000 0000 0000 0010 0000 > 0000260 0008 0000 0000 0000 0000 0000 0000 0000 < 0000280 0002 0000 0003 0000 0101 0000 0000 0000 > 0000280 0001 0000 0003 0000 0101 0000 0000 0000 offset 4 is CDSFileMapHeaderBase::_crc offset 0x268 is FileMapHeader::_narrow_oop_base offset ox270 is FileMapHeader::_narrow_oop_shift _crc is the checksum of the header. It is different because _narrow_oop_base/shift are different. _narrow_oop_base/shift may get non-deterministic behavior on Windows because the Java heap is mapped at different locations due to ASLR (address space layout randomization). Because of this, we actually disable CDS heap archiving on Windows. _narrow_oop_base/shift are used only for archived heap, so it's safe to set them to zero when INCLUDE_CDS_JAVA_HEAP==0 (e.g., Windows).
06-05-2020
[~iklam] - Can you take a look at this? You pushed this test yesterday...
06-05-2020
This test was pushed yesterday as part of JDK-8241071.
06-05-2020