RFR: 8311993: Test serviceability/sa/UniqueVtableTest.java failed: duplicate vtables detected [v3]

[Chris Plummer]

On Wed, 28 Aug 2024 23:30:33 GMT, Alex Menkov <amenkov at 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