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 I thought it odd that we lookup symbols including the *, e.g. Duplicate vtable: 0x00007ffd233633d8: - CompiledMethod (extends CodeBlob) - CompiledMethod* (extends null) And iterating over agent.getTypeDataBase().getTypes(); we see e.g. jbyte, jbyte*, jbyte** which looks odd and unnecessary. We know what a pointer is, so not needing to lookup up "jbyte*" might be good also. But that might be more change than we want to do right now, so this double check looks good. ------------- Marked as reviewed by kevinw (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20684#pullrequestreview-2275335513
