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

[Tyler Steele]

On Wed, 29 Jun 2022 18:33:13 GMT, Volker Simonis <simonis 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.

Thanks for your feedback @simonis, @RealCLanger and @RealLucy.

> I would like to see a short comment, explaining why it is necessary to reset the compressed size.

I think this is a good suggestion, and it's on my todo list.

> This is all a little bit confusing. First of all I don't think that this issue is s390 related.

This is likely my mistake. A member of the Linux on s390 team reported the issue to me, and I must have assumed it was related to that platform. Sorry for the confusion; I have removed the s390 tag in JBS.

> Can you please report the following... Then, do the following

Yes. Though I won't have access to this system until next week. I will report back when I have this information.

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

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