7036144: GZIPInputStream readTrailer uses faulty available() test for end-of-stream

[toddjonker]

This is a clean backport of d3f3011, originally authored by @archiecobbs and reviewed by @jaikiran

The corresponding backport for JDK21 is https://github.com/openjdk/jdk21u-dev/pull/1897

Testing:

• [x] New regression test fails without the fix, passes with it
• [x] linux-x86_64-server-release: headless tiers 1-3

---

Progress

• [x] Change must not contain extraneous whitespace
• [x] Commit message must refer to an issue
• [x] Change requires CSR request JDK-8340729 to be approved
• [ ] JDK-7036144 needs maintainer approval

Issues

• JDK-7036144: GZIPInputStream readTrailer uses faulty available() test for end-of-stream (Bug - P4 - Requested)
• JDK-8340729: GZIPInputStream readTrailer uses faulty available() test for end-of-stream (CSR)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk17u-dev.git pull/3667/head:pull/3667
$ git checkout pull/3667

Update a local copy of the PR:
$ git checkout pull/3667
$ git pull https://git.openjdk.org/jdk17u-dev.git pull/3667/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 3667

View PR using the GUI difftool:
$ git pr show -t 3667

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk17u-dev/pull/3667.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper[bot]]

:wave: Welcome back toddjonker! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk[bot]]

❗ This change is not yet ready to be integrated. See the Progress checklist in the description for automated requirements.

[openjdk[bot]]

This backport pull request has now been updated with issue from the original commit.

[openjdk[bot]]

⚠️ @toddjonker This change is now ready for you to apply for maintainer approval. This can be done directly in each associated issue or by using the /approval command.

[toddjonker]

/approval request This issue has been observed causing data loss.

[toddjonker]

/integrate auto

[openjdk[bot]]

@toddjonker 7036144: The approval request has been created successfully.

[mlbridge[bot]]

Webrevs

• 00: Full (88bf5687)

[GoeLin]

Hi @toddjonker Have you tested anything besides the jtreg tests mentioned above? This change modifies behaviour, this might have negative side effects, especially on the many working installations that receive this update. Oracle tried to backport, but they didn't deliver it. Usually, they have a good reason for this.
Do we need to rush this backport? I would rather defer it to the next (January) release to get experience with the change in 21. People can go to 21 or soon 25 if they have an issue.

[toddjonker]

Hi @GoeLin, I've not tested further. My expectation was that the "bake time" sufficient to backport to 21 was sufficient for earlier releases.

People can go to 21 or soon 25 if they have an issue.

In the environment I support, we cannot assume that JDK updates, especially from older releases (like 11), are straightforward; in fact they can be quite costly. I'd personally rather prevent the inevitable-at-scale data loss than tell customers they have to update to avoid it.

Anyway, it sounds like you'd prefer we hold off on this for a while, so I'll update our own issue tracking and then pull this back into draft status.

[GoeLin]

Hi @toddjonker I'm sorry, I'm really getting careful lately because we see too many regressions in every update and the rate of backports seems to go up instead of down. I'll label it defer-next and probably approve for the January update.

[openjdk[bot]]

@toddjonker JCheck configuration is invalid in the target branch of this pull request. Please issue this command again once the problem has been resolved.

[bridgekeeper[bot]]

@toddjonker This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply issue a /touch or /keepalive command to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

[Rudometov]

/keepalive

[openjdk[bot]]

@Rudometov The pull request is being re-evaluated and the inactivity timeout has been reset.

[bridgekeeper[bot]]

@toddjonker This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply issue a /touch or /keepalive command to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

[Rudometov]

/keepalive

[openjdk[bot]]

@Rudometov The pull request is being re-evaluated and the inactivity timeout has been reset.

[bridgekeeper[bot]]

@toddjonker This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply issue a /touch or /keepalive command to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

[bridgekeeper[bot]]

@toddjonker This pull request has been inactive for more than 8 weeks and will now be automatically closed. If you would like to continue working on this pull request in the future, feel free to reopen it! This can be done using the /open pull request command.

[Rudometov]

/open

[openjdk[bot]]

@Rudometov Only the pull request author can set the pull request state to "open"

[toddjonker]

/open

[openjdk[bot]]

@toddjonker This pull request is now open