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

src/jdk.hotspot.agent/windows/native/libsaproc/sawindbg.cpp line 867:

> 865:   char buf[SYMBOL_BUFSIZE];
> 866:   memset(buf, 0, sizeof(buf));
> 867:   if (ptrIDebugSymbols->GetNameByOffset(offset, buf, sizeof(buf), 0, 
> &disp) ==  S_OK) {

Nit: Extra space before `S_OK`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20684#discussion_r1735332182

Reply via email to