On Tue, 16 Feb 2021 23:28:28 GMT, Chris Plummer <[email protected]> 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
