On Wed, 28 Aug 2024 23:30:33 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: > > removed extra space Anyway failures with disableNativeLookup and UseSharedSpaces is different issue. I can file JBS issue, but to me disableNativeLookup looks like development property. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20684#issuecomment-2316521998
