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. ------------- Commit messages: - Use p_memsz instead of p_filesz to correctly compute segment size. Changes: https://git.openjdk.java.net/jdk/pull/4075/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4075&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263242 Stats: 4 lines in 1 file changed: 1 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4075.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4075/head:pull/4075 PR: https://git.openjdk.java.net/jdk/pull/4075
