-
Notifications
You must be signed in to change notification settings - Fork 162
8315135: Memory leak in the native implementation of Pack200.Unpacker.unpack() #361
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
👋 Welcome back simonis! A progress list of the required criteria for merging this PR into |
This backport pull request has now been updated with issue from the original commit. |
/clean |
@simonis This backport pull request is now marked as clean |
@simonis This change now passes all automated pre-integration checks. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 2 new commits pushed to the
Please see this link for an up-to-date comparison between the source branch of this pull request and the ➡️ To integrate this PR with the above commit message to the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Backport looks ok (though not clean due to the context difference)
Thanks @gnu-andrew! Regarding the "clean" label, I was a little confused by the following line in the OpenJDK Backports Wiki:
And I actually still don't fully understand what exactly "Note that only the changes have to be identical, not the changed lines" means? |
/integrate |
Going to push as commit 6632d0a.
Your commit was automatically rebased without conflicts. |
It's the first time I've seen that myself and I agree it's confusing. I think the intention may be to imply that it's clean if you make the same code changes even if they are in a different place in the file or even a different file. To me, that would be going a bit far. The approach I've always used, even before we used GitHub and Skara, is that a backport is clean if it can be automated by tools i.e. if you apply the shuffle script, and then run Even the former can be problematic if patch fuzzes the change into the wrong place, so I would be cautious even in those cases. That's why I actually quite like that 8u doesn't automatically add |
Hi all,
This pull request contains a backport of commit b77c161e from the openjdk/jdk11u-dev repository.
The commit being backported was authored by Volker Simonis on 30 Aug 2023 and was reviewed by Christoph Langer and Thomas Stuefe.
The backport applies cleanly except for the usual 11/8 directory shuffling and the following cosmetic context change in
jni.cpp
:Thanks!
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk8u-dev.git pull/361/head:pull/361
$ git checkout pull/361
Update a local copy of the PR:
$ git checkout pull/361
$ git pull https://git.openjdk.org/jdk8u-dev.git pull/361/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 361
View PR using the GUI difftool:
$ git pr show -t 361
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk8u-dev/pull/361.diff
Webrev
Link to Webrev Comment