On Mon, 26 Aug 2024 22:25:34 GMT, Alex Menkov <amen...@openjdk.org> wrote:
>> On Windows SA agent gets a class vtable from symbols, exported from jvm.dll
>> (it exports symbols like "??_7" + type + "@@6B@").
>> But symbol lookup function first requests WinDbg about the symbol.
>> Sometimes WinDbg routine IDebugSymbols::GetOffsetByName() returns offset for
>> both class and class pointer types. Returned offsets correspond to symbols
>> like "jvm!class_name::`vftable'".
>> The behavior is intermittent, I was not able to find what is the reason.
>> The fix adds workaround for the case - if GetOffsetByName succeeded, we
>> check if corresponding symbol contains requested one.
>> So it returns expected offset for non-vtable symbols like
>> "MaxJNILocalCapacity" (GetOffsetByName returns offset for
>> "jvm!MaxJNILocalCapacity"), but returns 0 for vtlb lookup.
>>
>> Additionally added check for results of
>> IDebugSymbols::SetImagePath/SetSymbolPath
>>
>> Testing: tier1,tier2,hs-tier5-svc
>
> Alex Menkov has updated the pull request incrementally with one additional
> commit since the last revision:
>
> use SYMBOL_BUFSIZE
public boolean isSharingEnabled() {
if (sharingEnabled == null) {
Address address = VM.getVM().getDebugger().lookup(null,
"UseSharedSpaces");
if (address == null && getOS().equals("win32")) {
// On Win32 symbols are prefixed with the dll name. So look for
// UseSharedSpaces as a symbol in jvm.dll.
address = VM.getVM().getDebugger().lookup(null,
"jvm!UseSharedSpaces");
}
sharingEnabled = address.getJBooleanAt(0);
}
return sharingEnabled.booleanValue();
}
I'm not sure why this is failing. Based on the existing code and comments, it
seems at some point SA worked without relying on the windbg native symbol
support. Code like isSharingEnabled() probably got added afterwards and was
never tested with it disabled.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/20684#issuecomment-2314139076
