On Sun, 28 Sep 2025 21:19:42 GMT, Francesco Andreuzzi <[email protected]> wrote:
>> The problem seems to be in read_lib_segments (ps_core.c), this check is too >> harsh: >> >> https://github.com/openjdk/jdk/blob/5271448b3a013b2e3edcd619a4a3b975b292dae1/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c#L423-L425 >> >> In my run, `existing_map->memsz = 0xe24000`, while the rhs in L425 is >> `0xe23000`. According to the NT_FILE entry, this segment of `libjvm.so` has >> file offset 0x67f000. It seems that the linker aligned it down according to >> the page size (0x1000). The offset of the same segment according to `readelf >> -l libjvm.so` is 0x67fc80. This additional offset should be added to >> `p_memsz` to obtain the 0xe24000, which we see in the core dump. >> >> I added some files to the ticket for context. >> >> Passes `tier1` and `tier2`. > > Francesco Andreuzzi has updated the pull request with a new target base due > to a merge or a rebase. The incremental webrev excludes the unrelated changes > brought in by the merge/rebase. The pull request contains 11 additional > commits since the last revision: > > - new check > - Merge branch 'master' into JDK-8367609 > - nn > - comment and rename > - invert > - review > - simplify > - fix > - simple fix > - fix > - ... and 1 more: https://git.openjdk.org/jdk/compare/81ac630a...70eaa2bb OK glad it works. 8-) Maybe a comment above line 423 so say something like: // Account for the PH being at some vaddr offset from mapping in core file. We could have left the ROUNDUP on line 427 to the comparison on line 431 to make it more like the original. I think either way is good. Good for me, let's check Chris who looked at it also agrees. ------------- Marked as reviewed by kevinw (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27274#pullrequestreview-3278976960
