On Tue, 16 Sep 2025 08:22:10 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 incrementally with two > additional commits since the last revision: > > - nn > - comment and rename Thanks - does that still have the same problem? (Do you have the jtreg log from this one, to confirm I was looking at the right address here...) libjvm second seg: core: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align LOAD 0x0000000006b23000 0x00007fa9ff881000 0x0000000000000000 0x0000000000e23000 0x0000000000e23000 R E 0x1000 libjvm binary: LOAD 0x0000000000680180 0x0000000000681180 0x0000000000681180 0x0000000000e226c0 0x0000000000e226c0 R E 0x1000 These figures look like they work, for that check which has been working for gcc builds: ROUNDUP(existing_map->memsz, page_size) != ROUNDUP(lib_php->p_memsz, page_size) left: core file memsize: 0x0000000000e23000 right: lib mem size 0x0000000000e226c0 rounds to 0xe23000 Was core 1 different? Looks like a slightly smaller libjvm in that run (mem size was 0e225c0 and the core contained a 0xe24000 size mapping, which was the problem). ------------- PR Comment: https://git.openjdk.org/jdk/pull/27274#issuecomment-3306693613
