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

Lance Andersen lance.andersen at oracle.com
Fri Jul 9 16:11:48 UTC 2021


Hi Jaikiran,

On Jul 9, 2021, at 8:43 AM, Jaikiran Pai <jai.forums2013 at gmail.com<mailto:jai.forums2013 at gmail.com>> wrote:


On 05/07/21 10:52 am, Jaikiran Pai wrote:

4. I've never previously created a manual test case. The `LargeCompressedEntrySizeTest` in this PR is expected to be a manual test case (given how long it might take to run on various different systems). The only difference between this test case and other jtreg automated tests is the absence of a `@test` on this one. Is this how manual tests are written or is there some other way?

We avoid manual tests as there is no guarantee that they will be run. So maybe we'll need to explore the scenario a bit further to see if there is some way to come up with an automated test. The jtreg foo for manual tests is `@run main/manual LargeCompressedEntrySizeTest`. You'll see a few examples in the test suite but I don't know if they are ever run.

I have updated the PR to use jtreg's construct of @run testng/manual to mark this as a manual test. I will post the timing of this test case later today after I run the latest version locally and see how long it's taking.

On my local setup, the LargeCompressedEntrySizeTest (latest version of this PR) consistently takes between 205 to 215 seconds to complete (so between 3 to 4 minutes). Is that something that will allow it to be added as part of automated tests or is it too long for automated tests?

Thank you for the info.  This test needs to remain a manual test.

I have a full test run going and will finish my review later today or tomorrow

Best
Lance

-Jaikiran

[cid:E1C4E2F0-ECD0-4C9D-ADB4-B16CA7BCB7FC at home]



Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com<mailto:Lance.Andersen at oracle.com>





More information about the core-libs-dev mailing list