On Tue, 10 Mar 2026 04:55:20 GMT, Yasumasa Suenaga <[email protected]> wrote:

> On CentOS 7 (glibc-2.17-326.el7_9.3.x86_64), ld-2.17.so is mapped like 
> following:
> 
> 
> 7f830b42c000-7f830b44e000 r-xp 00000000 08:04 202220966 /usr/lib64/ld-2.17.so
> 
> 
> However SA maps it as following. Base address is correct, but end address is 
> different from "maps".
> 
> 
> libsaproc DEBUG: /usr/lib64/ld-2.17.so [0] 0x7f830b42c000-0x7f830b62c000: 
> base = 0x7f830b42c000, vaddr = 0x0, memsz = 0x21960, filesz = 0x21960
> 
> 
> We fixed calculation logic in 
> [JDK-8377395](https://bugs.openjdk.org/browse/JDK-8377395) to align end 
> address to align `p_align` in ELF header, but the logic seems to be incorrect 
> (note that the calculation is working as expected).
> 
> Linux Kernel 
> ([fs/binfmt_elf.c](https://github.com/torvalds/linux/blob/v6.19/fs/binfmt_elf.c#L414))
>  aligns end address with page size, not `p_align`. So SA might need to follow 
> it. Otherwise address it might happen address confliction what we saw in 
> [JDK-8377395](https://bugs.openjdk.org/browse/JDK-8377395).

OK, I would have expected p_align to be ignored if less than page size,
but Linux just ignores p_align and uses pagesize. 8-)

The high address 0x7f830b62c000 suggests p_align was higher in this case, 
0x200000 2MB ?
(Unfortunately we don't show p_align when we print all the other details on 
line 196...)

Expect the distributions we test have p_align equal to pagesize, so should be 
unaffected.

-------------

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/30154#pullrequestreview-3928110436

Reply via email to