Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8315698

Crash when comparing BasicType as int after JDK-8310577

    XMLWordPrintable

Details

    • b15
    • x86_64
    • windows

    Description

      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.

      Attachments

        Issue Links

          Activity

            People

              djelinski Daniel Jelinski
              djelinski Daniel Jelinski
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: