We have the following call chain:

VMError::report
  os::print_register_info
    CodeBlob::dump_for_addr
      AdapterHandlerLibrary::contains

where:

bool AdapterHandlerLibrary::contains(const CodeBlob* b) {
  bool found = false;
  auto findblob = [&] (AdapterFingerPrint* key, AdapterHandlerEntry* a) {
    return (found = (b == CodeCache::find_blob(a->get_i2c_entry())));
  };
  assert_locked_or_safepoint(AdapterHandlerLibrary_lock);
  _adapter_handler_table.iterate(findblob);
  return found;
}

but we don't hold the lock, nor are we at a safepoint.

This was spotted in one of the tests that deliberately crashes the VM. The hs_err file shows:

Register to memory mapping:

RIP=0x00007ffaf5ab1000 LingeredApp.dll
RAX=0x00007ffaf5ab1000 LingeredApp.dll
RBX={method} {0x0000023fd4401dc0} 'crash' '()I' in 'jdk/test/lib/apps/LingeredApp'
RCX=0x0000023fb77581e0 points into unknown readable memory: 0x00007ffaeaeede60 | 60 de ee ea fa 7f 00 00
RDX=0x000000f29a5ff1b8 is pointing into the stack for thread: 0x0000023fb7757ec0
RSP=0x000000f29a5ff138 is pointing into the stack for thread: 0x0000023fb7757ec0
RBP=0x000000f29a5ff1a8 is pointing into the stack for thread: 0x0000023fb7757ec0
RSI=0x000000000000000c is an unknown value
RDI=0x0000023fd4017ac0 is pointing into metadata
R8 ={method} {0x0000023fd4401dc0} 'crash' '()I' in 'jdk/test/lib/apps/LingeredApp'
R9 =
[error occurred during error reporting (printing register info), id 0xe0000000, Internal Error (c:\sb\prod\1677455098\workspace\open\src\hotspot\share\runtime\mutexLocker.cpp:179)]

and the Windows debugger stack dump showed the problematic call chain.