On Wed, 12 Jun 2024 14:02:58 GMT, fitzsim <d...@openjdk.org> wrote: > 8334048: -Xbootclasspath can not read some ZIP64 zip files
It turns out ZIP64 is underrepresented in the test suite in general; for example, https://bugs.openjdk.org/browse/JDK-8185896 is still open. Using the Java class library alone, I have not been able to produce a ZIP file that demonstrates this issue. I have ideas about how the standard ZIP classes could be modified to produce small ZIP64 files suitable for testing various code paths. I was able to produce a small ZIP file using the Info-ZIP command line tool that does demonstrate the issue. To keep the test setup simple, I inlined the ZIP file as byte constants in `BootClassPathZip64Creator`, the driver for `BootClassPathZip64Test`. Next I am going to check the code coverage provided by this test case for the proposed `zip_util.c` fix. I saw and looked into this failure: `2024-07-03T09:37:42.6540920Z at ZipSourceCache.testKeySourceMapping(ZipSourceCache.java:102)` ... `Suppressed: java.nio.file.FileSystemException: 1719999454994-bug8317678.zip: The process cannot access the file because it is being used by another process` but I could not see how `zip_util.c` could cause that. I re-ran [windows-x64 / test (jdk/tier1 part 2)](https://github.com/fitzsim/jdk/actions/runs/9774287212/job/26997159267) and that issue resolved itself. I am not sure at this point if this could be caused by the `zip_util.c` changes, or if it is a transient `windows-x64` builder issue. I was able to get the same _"invalid CEN header (bad signature)"_ error for `-Xbootclasspath` with a ZIP file generated using the `ZipFileSystem` API, using `Map<String, Object> env = Map.of("create", "true", "forceZIP64End", "true");` like `readZip64EndZipFs` does in `test/jdk/java/util/zip/ZipFile/ReadZip.java` (https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/zip/ZipFile/ReadZip.java#L230). Given it is the same failure mode, I am inclined not to add a Java part to the test case. I noticed that `readZip64EndInfoZIPStreaming` in that same test case uses the approach I found independently for creating a small ZIP64 file, and it also inlines the bytes of that small ZIP file. Therefore the inlining approach in `BootClassPathZip64Creator` does not regress [JDK-8321616](https://bugs.openjdk.org/browse/JDK-8321616). I still would like to exercise at least one branch of the heuristics conditional with another test case, so I will work on that next. At that point, I suspect one could argue that [JDK-8185896](https://bugs.openjdk.org/browse/JDK-8185896) is addressed, unless one would prefer to create another set of expensive tests using large-payload ZIP64 files. This patch set is ready for review. I was able to eliminate the Info-ZIP dependency and shrink the test logic significantly. I added two new test cases, one for non-ZIP64 ZIP files, and one for a ZIP64 file with magic values in CEN, both of which worked before and continue to work with the fix proposed in this pull request. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19678#issuecomment-2204456736 PR Comment: https://git.openjdk.org/jdk/pull/19678#issuecomment-2206421991 PR Comment: https://git.openjdk.org/jdk/pull/19678#issuecomment-2229497634 PR Comment: https://git.openjdk.org/jdk/pull/19678#issuecomment-2261474735
