RFR: 8261710: SA DSO objects have sizes that are too large
Yasumasa Suenaga
ysuenaga at openjdk.java.net
Thu Feb 18 02:48:38 UTC 2021
On Sun, 14 Feb 2021 07:14:24 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:
> This PR relates to [JDK-8261702](https://bugs.openjdk.java.net/browse/JDK-8261702) ( #2562 )
> When SA creates a DSO object, which is used to represent a shared object file (.so), it initializes the "size" to be the size of the shared object file. This usually results in the size being too big. This can cause SA to get confused about whether or not an address is in the shared object. SA should instead set the DSO's size to the amount of the file that is actually mapped for executable code.
> @YaSuenag https://bugs.openjdk.java.net/browse/JDK-8250826 is the bug I was thinking of that sounds like the RO/RW issue you were talking about.
It is similar, but it's different from this issue because JDK-8250826 is caused by `mprotect()` call against memory segment in ELF binary.
> In any case, I think the main issue it causes for you is that your rounding up the size of the last (4th) segment may not enough. I think in most cases you would need to round it up to a page boundary, and then add another page to it.
Hmm... it might be page-boundary problem as you said, but I don't have any ideas where we can collect the information about that excepting note section in the core.
My latest patch shows following debug message on the console. It shows all PT_LOAD segments have been handled correctly.
libsaproc DEBUG: /lib64/libnss_sss.so.2 [0] 0x7f0ba6ec5000-0x7f0ba6ec7000: base = 0x7f0ba6ec5000, vaddr = 0x0, memsz = 0x1468, filesz = 0x1468
libsaproc DEBUG: /lib64/libnss_sss.so.2 [1] 0x7f0ba6ec7000-0x7f0ba6ece000: base = 0x7f0ba6ec5000, vaddr = 0x2000, memsz = 0x6931, filesz = 0x6931
libsaproc DEBUG: /lib64/libnss_sss.so.2 [2] 0x7f0ba6ece000-0x7f0ba6ed0000: base = 0x7f0ba6ec5000, vaddr = 0x9000, memsz = 0x1110, filesz = 0x1110
libsaproc DEBUG: /lib64/libnss_sss.so.2 [3] 0x7f0ba6ed0000-0x7f0ba6ed1000: base = 0x7f0ba6ec5000, vaddr = 0xbc78, memsz = 0x658, filesz = 0x44c
> I'm actually not too concerned about getting this right, because with my PointerFinder workaround I don't think this issue with the map sizes has much impact on SA. Probably the only place it will show up is with SA pmap output.
Ok, I will move forward this fix.
-------------
PR: https://git.openjdk.java.net/jdk/pull/2563
More information about the serviceability-dev
mailing list