RFR: 8261710: SA DSO objects have sizes that are too large

Chris Plummer cjplummer at openjdk.java.net
Wed Feb 17 00:15:38 UTC 2021


On Tue, 16 Feb 2021 23:28:28 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Dan included the logs of the failures in the CR. This is what they show:
>> 
>>   + findpc 0x00002b77f084d116
>> Address 0x00002b77f084d116: /lib/x86_64-linux-gnu/libnss_files.so.2 + 0x21b116
>> ...
>> java.lang.RuntimeException: Test ERROR java.lang.RuntimeException: 'In interpreter codelet' missing from stdout/stderr
>
> I should add that the failures Dan is seeing are with #id3, which is no -Xcomp, but with a core file instead of a live process. With -Xcomp this part of the test is not run, so possibly this is just an issue with the dso size calculation for core files, and works correctly with a live process.

If you run ClhsdbPmap.java, you can see pmap output for both core and live processes. The sizes of the maps are very large for both of them, and actually a bit bigger with the live process. Here's the output for a live process:

0x000014755360c000	4048K	/usr/lib64/libnss_sss.so.2
0x0000147553815000	4012K	/usr/lib64/libnss_files-2.17.so
0x0000147560208000	4064K	/usr/lib64/libm-2.17.so
0x000014756050a000	3032K	/usr/lib64/librt-2.17.so
0x0000147560712000	32892K	/scratch/cplummer/ws/jdk/jdk.clean/build/linux-x64-debug/images/jdk/lib/server/libjvm.so
0x0000147562731000	4924K	/usr/lib64/libc-2.17.so
0x0000147562aff000	3076K	/usr/lib64/libdl-2.17.so
0x0000147562d03000	3060K	/usr/lib64/libpthread-2.17.so
0x0000147562f1f000	2948K	/usr/lib64/libz.so.1.2.7
0x0000147563135000	2860K	/usr/lib64/ld-2.17.so
0x0000147563164000	92K	/scratch/cplummer/ws/jdk/jdk.clean/build/linux-x64-debug/images/jdk/lib/libnet.so
0x000014756317b000	80K	/scratch/cplummer/ws/jdk/jdk.clean/build/linux-x64-debug/images/jdk/lib/libnio.so
0x00001475631e0000	156K	/scratch/cplummer/ws/jdk/jdk.clean/build/linux-x64-debug/images/jdk/lib/libjava.so
0x0000147563207000	128K	/scratch/cplummer/ws/jdk/jdk.clean/build/linux-x64-debug/images/jdk/lib/libjimage.so
0x000014756332c000	68K	/scratch/cplummer/ws/jdk/jdk.clean/build/linux-x64-debug/images/jdk/lib/libjli.so
0x0000563c950bf000	16K	/scratch/cplummer/ws/jdk/jdk.clean/build/linux-x64-debug/images/jdk/bin/java
`/usr/lib64/libnss_files-2.17.so` is the one that turned up in the test failure. It's only a 68k file but has a 4064k map. It's second in the list. I'm not sure if this is the order we would always see on linux systems. My assumption was it was the library at the highest address that was causing the problem, and that the inteprerter was located right after it, but that might not be the case.

The address in the interpreter that we are doing findpc on turned up at `libnss_files.so.2 + 0x21b116`, or at an offset of 2200k. I added a "pmap" command to ClhsdbFindPC, and from my test runs the interpreter seemed to alway be just before the first library. However, maybe on some systems it is intermixed with the libraries.

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

PR: https://git.openjdk.java.net/jdk/pull/2563


More information about the serviceability-dev mailing list