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

Chris Plummer cjplummer at openjdk.java.net
Tue Feb 16 23:31:39 UTC 2021


On Tue, 16 Feb 2021 22:51:34 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>>> I updated patch for macOS. I cannot test it, but all of tier 1 servicerbility tests were passed on GitHub Actions. Could you review again?
>> 
>> The OSX changes look good and passed my testing. However as Dan indicated above, it seems with your changes in place the original problem is still being reproduced. Note the original problem never reproduced with the testing I've been doing, so my testing doesn't prove that you fixed the issue. However, Dan is running on a local host that does reproduce the issue pretty reliably, and seems to still reproduce it after your fixes.
>
> 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.

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

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


More information about the serviceability-dev mailing list