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

Validate more special case invocations

    XMLWordPrintable

Details

    • Bug
    • Resolution: Fixed
    • P3
    • 11
    • 10, 11
    • core-libs
    • None

    Description

      There is some laxity in the verifier when it comes to checking interface method calls, compared to non-interface calls. This has led to some missing receiver type checks in the VM invocation paths and MethodHandle invocation paths, which have been fixed over time. There remains an issue with invokespecial of interface methods.

      JDK-8168699 dealt with direct bytecode invocation modes (ie invokespecial) but did not make any changes to Methodhandle invocations. JDK-8174962 made further changes for invokeInterface, including MethodHandle invocation, but private interface methods use invokeSpecial. So the case of a MethodHandle based invokeSpecial invocation is not covered.

      If we take the test written for 8174962 and adapt it to use private methods then we hit an assertion failure during MethodHandle verification:

      # Internal Error (/export/users/dh198349/jdk-hs/open/src/hotspot/cpu/x86/macroAssembler_x86.cpp:895), pid=7516, tid=7545
      # assert(false) failed: DEBUG MESSAGE: receiver class disagrees with MemberName.clazz
      #

      The low-level check has detected the incorrect receiver type that should actually be detected at a higher level and IncompatibleClassChangeError thrown.

      Attachments

        Issue Links

          Activity

            People

              dholmes David Holmes
              dholmes David Holmes
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: