Bug ID: JDK-8217166 tools/jlink/JLinkReproducibleTest.java fails frequently

Reclosing as "Cannot Reproduce" instead of Resolving as...
11-10-2023
As noted in previous comments in this issue, several issues were fixed in this area and the test is no longer part of the problem list. This test hasn't failed for a couple of years now. I'll resolve this as no longer reproducible.
10-10-2023
To add to what Alan notes - we recently removed this test from the problem list as part of https://bugs.openjdk.java.net/browse/JDK-8276688. As noted in that issue, the recent fix for https://bugs.openjdk.java.net/browse/JDK-8275509 has shown that these failures are no longer occuring.
01-12-2021
There are several issues fixed since this bug was created and the test is no longer excluded. So I think this JBS issue can be closed. A new bug has been created if there are any sightings in the future.
30-11-2021
[~jpai] That just tells us that there are different number of ImageLocations between those two modules files. I'm afraid that in itself is not enough for us to debug further. Perhaps if we can capture the modules files we may be able to inspect/debug.
28-05-2021
I've tried to reproduce this issue by running the test multiple times in a loop on various different setups (MacOS and CentOS) and haven't been able to reproduce it so far. However, assuming that the more than one instance of logs that have been pasted in this issue so far, are from multiple runs, then one thing is consistent and I think a hint: java.lang.RuntimeException: assertEquals: expected -1 to equal 20 The above check failure is from: assertEquals(-1L, Files.mismatch(firstModulesFile, secondModulesFile)); The Files.mismatch API states: @return the position of the first mismatch or {@code -1L} if no mismatch So the failure shows that these files (lib/modules) of these 2 images always differ starting at the 21st byte, which happens to be the header area of the images. And 21st byte corresponds to (see jdk.internal.jimage.ImageHeader#writeTo(ByteBuffer buffer)): buffer.putInt(magic); // 4 bytes buffer.putInt(majorVersion << 16 \| minorVersion); // 4 bytes buffer.putInt(flags); // 4 bytes buffer.putInt(resourceCount); // 4 bytes buffer.putInt(tableLength); // 4 bytes buffer.putInt(locationsSize); // 4 bytes so the 21st byte is "locationsSize" and that is what seems to be differing. This in itself doesn't tell why or which specific reason is differing, but at least might be a hint for others who know this area more and might know where to look for when this happens next.
27-05-2021
Also seeing this fail on Ubuntu 18.04.5 running on X86_64.
11-02-2021
[~dcubed] I think the direct cause of the failure of JLinkReproducibleTest.java is unrelated to CDS. This test runs $JAVA_HOME/bin/jlink with various options to produce a new JDK image. jlink doesn't internally invoke "java -Xshare:dump", nor does it copy the default CDS image into the new JDK image. JDK-8253500 ([REDO] JDK-8253208 Move CDS related code to a separate class) seems an innocuous change in the core library. Interestingly, a new class (jdk.internal.misc.CDS) is added to the very early stage of the JDK bootstrap code. This new class seems to cause the bootstrap code to run in an unstable order (possibly involving multiple threads). This unstable order has revealed timing-related bugs in CDS: JDK-8253262 Allocate in DumpRegion is not thread safe JDK-8253495 runtime/cds/DeterministicDump.java broken after JDK-8253208 I think JLinkReproducibleTest.java is also caused by a timing-related bug (in jlink), which is somehow tickled by JDK-8253500. We should problem-list JLinkReproducibleTest.java for now to reduce noise in the CI, before the underlying bug is fixed.
26-09-2020
First failure sighting on linux-aarch64 was in jdk-16+17-794, but the test started failing more frequently on linux-aarch64 in jdk-16+18-821. Anyone have an idea what caused an increase in the frequency? We should probably ProblemList this test on linux-aarch64 to reduce the noise in CI Tier2. Update: The only changeset in jdk-16+17-794 is for Shenandoah so that's not what caused this failure to start on linux-aarch64.
25-09-2020
JDK-8252730 fixes another reproducibility issue so should make things better.
25-09-2020
This seems to be failing all the time on aarch64 now.
25-09-2020
If dropping `--compress=2` "fixes" the issue then it suggests the issue in the compress mode, that will need to be studied to track down the issue.
12-03-2020
Suggested Fix: --- a/test/jdk/tools/jlink/JLinkReproducibleTest.java +++ b/test/jdk/tools/jlink/JLinkReproducibleTest.java @@ -49,7 +49,6 @@ cmd.addAll(List.of( "--module-path", JMODS_DIR.toString() + File.pathSeparator + CLASS_DIR.toString(), "--add-modules", "main", - "--compress=2", "--output", image.toString() )); if (!with_default_trace_file) {
12-03-2020
This doesn't seem to be a new issue in JDK 14 and probably should be a changed to a P3 targeted to 15. [~amlu] Did you capture the two lib\modules files that were created with --compress 2 but aren't bitwise identical? I think that would help narrow down the issue, esp. the puzzling bit that it only shows up on Windows.
24-01-2020
Deferral Request intermittent platform specific test failure, added to problem list already. No fix known as of now.
16-01-2020
The test failure is intermittent and windows specific. Would like to defer this issue.
16-01-2020
This test has been added to ProblemList.txt for windows-all (JDK-8233961). Please remember to take it back when fixing this (JDK-8217166) issue.
13-11-2019
This more likely a testbug. Two zip files can be different even if the contents are the same. This test is for JDK-8214230, in which reported "Classes generated by SystemModulesPlugin.java are not reproducable". Should the test check whether the "contents" are the same from the two moduleFiles (instead of check the difference of moduleFiles themselves)? Findings in detail: ============== Extracting the two test-created ModulesFiles (can be found in the test result directory), there is NO different in their contents (even though the ModulesFiles are diff): # diff reported for the modulefiles diff --brief --recursive JLinkReproducibleTest/image-first/ JLinkReproducibleTest/image-second/ Files JLinkReproducibleTest/image-first/lib/modules and JLinkReproducibleTest/image-second/lib/modules differ diff JLinkReproducibleTest/image-first/lib/modules JLinkReproducibleTest/image-second/lib/modules Binary files JLinkReproducibleTest/image-first/lib/modules and JLinkReproducibleTest/image-second/lib/modules differ # contents are the same jimage extract --dir modules-first /home/aginfra/temp/JLinkReproducibleTest/image-first/lib/modules jimage extract --dir modules-second /home/aginfra/temp/JLinkReproducibleTest/image-second/lib/modules diff --brief --recursive modules-first/ modules-second/ (NO diff reported) From the test code: It creates the images/modules with `jlink ... --compress=2` (which means: Enable compression of resources 2: ZIP), then try to compare them with: 114: // Ensure module files are identical 115: assertEquals(-1L, Files.mismatch(firstModulesFile, secondModulesFile)); Thus may result the two module files can be different even if their contents are the same: (from test log:) java.lang.RuntimeException: assertEquals: expected -1 to equal 20 at jdk.test.lib.Asserts.fail(Asserts.java:594) at jdk.test.lib.Asserts.assertEquals(Asserts.java:205) at jdk.test.lib.Asserts.assertEquals(Asserts.java:189) at JLinkReproducibleTest.main(JLinkReproducibleTest.java:115)
08-11-2019
This is a Tier2 test failure. Bumping the priority to P3.
14-08-2019
I ran test on Mac OS
13-05-2019
Ran that test with jtreg in a loop (20 times and then 50 times). I am not able to reproduce locally to debug it. The stack trace in the test failure does not give much to debug. Perhaps need to instrument the test...
13-05-2019
Upgrade to P2-P3 if warranted
16-01-2019

Relates :	JDK-8209176 - Check use of size hints when using compression entries
Relates :	JDK-8253688 - tools/jlink/JLinkReproducible3Test.java fails with "RuntimeException: jlink producing inconsistent result in modules. Mismatch in modules file"
Relates :	JDK-8233961 - Problem list tools/jlink/JLinkReproducibleTest.java for windows-all