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 Alex's changes neither introduce nor fix the isSharingEnabled() bug. It was just discovered out of an investigation to better understand how SA is doing symbol lookups on Windows. Basically we are trying to understand why it tries both windbg and dll lookups. Currently it won't work with just dll lookups, as the isSharingEnabled() failures show, but if that is the case how can dll lookups be a reliable fallback when windbg lookups fail. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20684#issuecomment-2316325685
