[jdk11u-dev] RFR: 8288763: [s390x] Pack200 extraction failure with invalid size

[Volker Simonis]

On Mon, 20 Jun 2022 23:03:33 GMT, Tyler Steele <tsteele at openjdk.org> wrote:

> While running some internal testing, a college has discovered a failure related to the Pack200 archive format on the zLinux platform. The problematic code was removed in the current repo by [JDK-8234596](https://bugs.openjdk.org/browse/JDK-8234596), however that change was large, and required a CSR. I feel that it would be too risky and cumbersome to backport those changes to jdk11 (and ultimately jdk8 as well), so I'd like to propose this change as a new change to jdk11 rather than via the usual backport process.
> 
> ### Testing
> These changes have been run against the failing test on zLinux and the Tier 1 tests completed successfully.

This is all a little bit confusing. First of all I don't think that this issue is s390 related. I think it should be independent of the platform and only depend on the source zip file and the zlib version used by the JDK. Unless we can't proof that this is indeed s390 related, please remove the "[s390]" tag from the summary to avoid further confusion.

>From the [JBS issue you've opened](https://bugs.openjdk.org/browse/JDK-8288763) I see that you're running JCK tests when you encountered this issue. You can find the source zip files of these tests under `tests/api/java_util/jar/Pack200/distributed/samples`. Can you please report the following:

- is the `libzip.so` of your JDK statically or dynamically linked against zlib (i.e. `ldd <path-to-jdk>/lib/libzip.so | grep libz`)
- the version of the system zlib (i.e. `/lib/x86_64-linux-gnu/libz.so.1 -> libz.so.1.2.11`)

Then, do the following:
- use `zipinfo -l <path-to-samples>/sample0X.jar` to verify the compressed size of the entries in the sample jar files
- use `unzip <path-to-samples>/sample0X.jar` to extract their contents and `jar cfm new_sample.jar META-INF/MANIFEST.MF *` to regenerate them with your JDK under test
- use `zipinfo -l new_sample.jar` again to verify the compressed sizes of the entries in the newly generated jar file

In the last step, if you find an entry with a compressed size which is different from the compressed size of that same entry in the original file then the root cause of your problem is indeed [JDK-8253952](https://bugs.openjdk.org/browse/JDK-8253952) as @RealCLanger suspected. I that case your fix is also correct and I'll be happy to approve it.

I agree with @RealCLanger that this issue is probably another variant of [JDK-8253952](https://bugs.openjdk.org/browse/JDK-8253952) (and that JBS issue has several links to other variants with the same root cause). I just want to make sure that we're really seeing the same issue here and don't have another hidden bug on s390.

-------------

PR: https://git.openjdk.org/jdk11u-dev/pull/1163