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 Actually I'm a bit confused on this. The extern "C" is making it so the dll lookup fails, but is it helping the windbg lookup to succeed? If yes, why did it ever get added if it was always first succeeding with the dll lookup. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20684#issuecomment-2316457056
