RFR: 8190753: (zipfs): Accessing a large entry (> 2^31 bytes) leads to a negative initial size for ByteArrayOutputStream [v2]

[Lance Andersen]

On Mon, 28 Jun 2021 09:13:31 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this proposed fix for the issue reported in https://bugs.openjdk.java.net/browse/JDK-8190753?
>> 
>> The commit here checks for the size of the zip entry before trying to create a `ByteArrayOutputStream` for that entry's content. A new jtreg test has been included in this commit to reproduce the issue and verify the fix.
>> 
>> P.S: It's still a bit arguable whether it's a good idea to create the `ByteArrayOutputStream` with an initial size potentially as large as the `MAX_ARRAY_SIZE` or whether it's better to just use some smaller default value. However, I think that can be addressed separately while dealing with https://bugs.openjdk.java.net/browse/JDK-8011146
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add @requires to the new test to selectively decide where the test runs

Thank you for looking into this issue.  

I ran your current test 150 times and the max runtime was 25 seconds, most cases were in the 18-20 second range on our slower test boxes.  

As part of looking at what happens with a file whose deflated size is > 2gb, I would add a specific test which is a manual test to validate that there is no issue when we cross the 2gb threshold.

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 1954:

> 1952:         } else {
> 1953:             os = new ByteArrayOutputStream((e.size > 0 && e.size <= MAX_ARRAY_SIZE)? (int)e.size : 8192);
> 1954:         }

The proposed change will address the specific issue shown in the bug.   As Alan points out, there could be an issue if the deflated size is > 2gb.  It would be good to look into that as part of your proposed fix.

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

PR: https://git.openjdk.java.net/jdk/pull/4607