-
Bug
-
Resolution: Unresolved
-
P4
-
None
-
11
-
None
-
Fedora 40 with system's Zlib-NG, see https://fedoraproject.org/wiki/Changes/ZlibNGTransition
NOTE: filing this on behalf of Antonio Vieiro avieirov at redhat.com, see https://mail.openjdk.org/pipermail/jdk-updates-dev/2024-June/034205.html
## Summary:
When configuring OpenJDK 11 --with-zlib=system (default) the PackTestZip64.java test in run-tests-tier1 fails [1] because it expects the generated files to be equal byte-to-byte, even though the uncompressed content is equal.
## Description:
PackTestZip64.java uses pack200 to repack, pack and unpack a [golden file `golden.jar`](test/jdk/tools/pack200/pack200-verifier/data/golden.jar). The result is then compared byte-to-byte with the original, and fails if the files differ, even when the files are equivalent.
The operations performed by PackTestZip64 are:
- Copies 'golden.jar' to `tools_java.jar` in a working directory.
- Runs `pack200 --repack tools_java.jar`.
- Runs `pack200 tools_pack.gz tools_java.jar`
- Runs `unpack200 tools_pack.gz tools_native.jar`
- Compares byte-to-byte the files `tools_native.jar` and `tools_java.jar` and files, and files if they differ in any byte.
## Rationale:
When OpenJDK is configured --with-zlib=system, the system zlib library may use different heuristics and compression ratios to each one of the entries of a zip file. As a consequence the zip files generated by the OpenJDK may differ in size to those generated by other tools, even though the extracted information is exactly equal.
## Proposed fix:
Instead of performing a byte-to-byte comparison of the files, the PackTestZip64 test should compare the **uncompressed information** of the files (number of entries, uncompressed size of entries, CRCs) to ensure that the files are equivalent. See [2] for an example that runs smoothly.
## Affected versions:
Affects JDK11 only. The PackTestZip64.java in JDK8 is different and does not perform a byte-to-byte comparison.
----
[1]
Extract of make run-tests-tier1 error on Fedora 40 with system's Zlib-NG
----
STDERR:
java.io.IOException: Files are differ starting at position: 43630
at PackTestZip64.compareTwoFiles(PackTestZip64.java:117)
at PackTestZip64.testPacking(PackTestZip64.java:89)
at PackTestZip64.main(PackTestZip64.java:48)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
at java.base/java.lang.Thread.run(Thread.java:829)
JavaTest Message: Test threw exception: java.io.IOException
JavaTest Message: shutting down test
----
[2]
https://github.com/vieiro/jdk11u-dev/blob/5337c07f3d09650a1f9a0946d10d1053646ae5b0/test/jdk/tools/pack200/PackTestZip64.java#L98
## Summary:
When configuring OpenJDK 11 --with-zlib=system (default) the PackTestZip64.java test in run-tests-tier1 fails [1] because it expects the generated files to be equal byte-to-byte, even though the uncompressed content is equal.
## Description:
PackTestZip64.java uses pack200 to repack, pack and unpack a [golden file `golden.jar`](test/jdk/tools/pack200/pack200-verifier/data/golden.jar). The result is then compared byte-to-byte with the original, and fails if the files differ, even when the files are equivalent.
The operations performed by PackTestZip64 are:
- Copies 'golden.jar' to `tools_java.jar` in a working directory.
- Runs `pack200 --repack tools_java.jar`.
- Runs `pack200 tools_pack.gz tools_java.jar`
- Runs `unpack200 tools_pack.gz tools_native.jar`
- Compares byte-to-byte the files `tools_native.jar` and `tools_java.jar` and files, and files if they differ in any byte.
## Rationale:
When OpenJDK is configured --with-zlib=system, the system zlib library may use different heuristics and compression ratios to each one of the entries of a zip file. As a consequence the zip files generated by the OpenJDK may differ in size to those generated by other tools, even though the extracted information is exactly equal.
## Proposed fix:
Instead of performing a byte-to-byte comparison of the files, the PackTestZip64 test should compare the **uncompressed information** of the files (number of entries, uncompressed size of entries, CRCs) to ensure that the files are equivalent. See [2] for an example that runs smoothly.
## Affected versions:
Affects JDK11 only. The PackTestZip64.java in JDK8 is different and does not perform a byte-to-byte comparison.
----
[1]
Extract of make run-tests-tier1 error on Fedora 40 with system's Zlib-NG
----
STDERR:
java.io.IOException: Files are differ starting at position: 43630
at PackTestZip64.compareTwoFiles(PackTestZip64.java:117)
at PackTestZip64.testPacking(PackTestZip64.java:89)
at PackTestZip64.main(PackTestZip64.java:48)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
at java.base/java.lang.Thread.run(Thread.java:829)
JavaTest Message: Test threw exception: java.io.IOException
JavaTest Message: shutting down test
----
[2]
https://github.com/vieiro/jdk11u-dev/blob/5337c07f3d09650a1f9a0946d10d1053646ae5b0/test/jdk/tools/pack200/PackTestZip64.java#L98
- links to
-
Review(master) openjdk/jdk11u-dev/2799