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

Extended NPE message doesn't handle CONSTANT_Dynamic

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: P4 P4
    • 24
    • 24
    • hotspot
    • b15

      While running my application with a fastdebug build, I see an assertion failure:

      ```
      #
      # A fatal error has been detected by the Java Runtime Environment:
      #
      # Internal Error (<redacted>/src/hotspot/share/interpreter/bytecodeUtils.cpp:660), pid=12677, tid=12678
      # assert(false) failed: Unexpected tag
      #
      # JRE version: OpenJDK Runtime Environment 1.0.1973.0 (17.0.12+6) (fastdebug build 17.0.12+6-LTS)
      # Java VM: OpenJDK 64-Bit Server VM 1.0.1973.0 (fastdebug 17.0.12+6-LTS, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
      # Problematic frame:
      # V [libjvm.so+0x73b2d8] ExceptionMessageBuilder::do_instruction(int)+0x2858
      ```
      with stack:
      ```
      V [libjvm.so+0x73b2d8] ExceptionMessageBuilder::do_instruction(int)+0x2858
      V [libjvm.so+0x73b591] ExceptionMessageBuilder::ExceptionMessageBuilder(Method*, int)+0x251
      V [libjvm.so+0x73de94] BytecodeUtils::get_NPE_message_at(outputStream*, Method*, int)+0x134
      V [libjvm.so+0x10bf625] JVM_GetExtendedNPEMessage+0x135
      j java.lang.NullPointerException.getExtendedNPEMessage()Ljava/lang/String;+0 java.base@17.0.12
      j java.lang.NullPointerException.getMessage()Ljava/lang/String;+23 java.base@17.0.12
      ```


      It seems that https://github.com/openjdk/jdk/blob/master/src/hotspot/share/interpreter/bytecodeUtils.cpp#L646-L660 does not handle `CONSTANT_Dynamic` for the `ldc` instruction, even though https://openjdk.org/jeps/309 says:

      > Dynamic constants must be usable in any context which currently allows general constant pool constants, such as CONSTANT_String and CONSTANT_MethodType. Thus, they must be valid operands to the ldc instruction and must be allowed as static parameters to bootstrap methods.

      I'm not sure if there's a reason this is not permitted (my application uses Kotlin and Jacoco so there could be some unusual bytecode generated), or if it's just an omission. I see that `ConstantPool::constant_tag_at` looks like it would be suitable for finding the underlying type of the dynamic constant.

            ogillespie Oli Gillespie
            ogillespie Oli Gillespie
            Votes:
            1 Vote for this issue
            Watchers:
            9 Start watching this issue

              Created:
              Updated:
              Resolved: