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
I found this:
// should we parse DLL symbol table in Java code or use
// Windbg's native lookup facility? By default, we use
// native lookup so that we can take advantage of '.pdb'
// files, if available.
useNativeLookup = true;
String str =
System.getProperty("sun.jvm.hotspot.debugger.windbg.disableNativeLookup");
if (str != null) {
useNativeLookup = false;
}
I'm not sure what is meant by "take advantage of '.pbp' files". Is it perhaps a
more reliable or complete database of symbols, or perhaps it is faster? In any
case, I'd be interested in seeing if all our tests still pass when
useNativeLookup is false.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/20684#issuecomment-2311592258
