Found in Java on Windows-x86 built with Clang in debug mode.

The build crashes during "Optimizing the exploded image" step with:

# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0000000170d395c0, pid=11812, tid=4188
#
# JRE version: OpenJDK Runtime Environment (22.0) (slowdebug build 22-internal-adhoc.djelinsk.open)
# Java VM: OpenJDK 64-Bit Server VM (slowdebug 22-internal-adhoc.djelinsk.open, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64)
# Problematic frame:
# j sun.nio.fs.WindowsNativeDispatcher.initIDs()V+0 java.base

The exact line varies from build to build; the common feature is that the problematic pointer has incorrect value in the top 32 bits.

Reason:
StubRoutines.call_stub is used to Java methods from native code, moving the arguments and result to where the code expects them. Due to a problem with handling the result type, all function return values are treated as 32-bit (T_INT); if the return value is 64 bit, the top 32 bits are replaced with whatever happens to be on the thread stack at the moment.

Details:
The top 32 bits are lost here:
https://github.com/openjdk/jdk/blob/9def4538ab5456d689fd289bdef66fd1655773bc/src/hotspot/cpu/x86/stubGenerator_x86_64.cpp#L331

This is because c_rarg2 contains the result type in the least-significant byte here: https://github.com/openjdk/jdk/blob/9def4538ab5456d689fd289bdef66fd1655773bc/src/hotspot/cpu/x86/stubGenerator_x86_64.cpp#L227

The remaining bytes of c_rarg2 are garbage. We are using the entire garbage value, so the result type is none of T_LONG, T_OBJECT, T_DOUBLE, or T_FLOAT, and the path for 32-bit T_INT is taken, which loses the top 32 bits.

The problem was introduced in JDK-8310577, which changed BasicType to u1. Before that change, c_rarg2 contained the result type in all bytes.