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

[Chris Plummer]

On Mon, 26 Aug 2024 22:25:34 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:
> 
>   use SYMBOL_BUFSIZE

public boolean isSharingEnabled() {
    if (sharingEnabled == null) {
        Address address = VM.getVM().getDebugger().lookup(null, "UseSharedSpaces");
        if (address == null && getOS().equals("win32")) {
            // On Win32 symbols are prefixed with the dll name. So look for
            // UseSharedSpaces as a symbol in jvm.dll.
            address = VM.getVM().getDebugger().lookup(null, "jvm!UseSharedSpaces");
        }
        sharingEnabled = address.getJBooleanAt(0);
    }
    return sharingEnabled.booleanValue();
  }


I'm not sure why this is failing. Based on the existing code and comments, it seems at some point SA worked without relying on the windbg native symbol support. Code like isSharingEnabled() probably got added afterwards and was never tested with it disabled.

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

PR Comment: https://git.openjdk.org/jdk/pull/20684#issuecomment-2314139076