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

Chris Plummer cjplummer at openjdk.java.net
Mon Feb 15 06:46: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.

These changes look good, but it would be nice to fix OSX too. Fortunately it should be easier. As part of the fix for [JDK-8247515](https://bugs.openjdk.java.net/browse/JDK-8247515), I added a `lib_info->memsz` field. I think it is correct and is what you need. I needed it in order to properly scan .dylibs for symbols without scanning too far. It seems to be working. Unfortunately we don't really have a good tests for this, but you could look at the before and after for ClhsdbPmap test to get an idea of if it is working. If you don't have an OSX machine to try, I can try out your changes for you.

BTW, I have no idea if Windows is getting the size right, but I guess we'll just have to assume it is:

    env->CallVoidMethod(obj, addLoadObject_ID, strName, (jlong) params[u].Size,
                        (jlong) params[u].Base);

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

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


More information about the serviceability-dev mailing list