8263242: serviceability/sa/ClhsdbFindPC.java cannot find MaxJNILocalCapacity with ASLR#4075
8263242: serviceability/sa/ClhsdbFindPC.java cannot find MaxJNILocalCapacity with ASLR#4075plummercj wants to merge 1 commit intoopenjdk:masterfrom
Conversation
|
👋 Welcome back cjplummer! A progress list of the required criteria for merging this PR into |
|
@plummercj The following label will be automatically applied to this pull request:
When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command. |
|
@plummercj This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. 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 10 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 |
|
Thanks for the reviews! |
|
/integrate |
|
@plummercj Since your change was applied there have been 18 commits pushed to the
Your commit was automatically rebased without conflicts. Pushed as commit 10236e7. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
The issue is that SA thought the library was smaller than it actually was, so SA refused to map an address to a symbol if the address was beyond what SA thought was the end of the library's memory range. However, the converse, mapping a symbol to an address, still worked even if the resulting address was thought to be out of range. This is because there was no range checking done in this case. Thus you could look up the address of a symbol, but then mapping the address back to a symbol might fail.
The root of the problem was using p_filesz instead of p_memsz when determining the size of a library segment, and there was also a rounding error once p_memsz was used, so it took a bit of extra logic to get the size computation just right. This comment in CR describes it best:
https://bugs.openjdk.java.net/browse/JDK-8263242?focusedCommentId=14408953&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14408953
There are also a bunch of p_filesz references in ps_core.c that should probably be p_memsz. However, I did some printfs and found the values to always be the same within core files, so decided not to risk making this change.
Progress
Issue
Reviewers
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/4075/head:pull/4075$ git checkout pull/4075Update a local copy of the PR:
$ git checkout pull/4075$ git pull https://git.openjdk.java.net/jdk pull/4075/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 4075View PR using the GUI difftool:
$ git pr show -t 4075Using diff file
Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/4075.diff