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

JDWP: JDWP command ThreadReference.forceEarlyReturn

    Details

    • Subcomponent:
    • CPU:
      generic
    • OS:
      generic

      Description

      JDWP spec for ThreadReference.ForceEarlyReturn says: "For methods that return primitive values, the value's type must match the return type exactly. For object values, there must be a widening reference conversion from the value's type to the return type type and the return type must be loaded"

      Test (it should be included in testbase r07)
      nsk/jdi/ThreadReference/forceEarlyReturn/forceEarlyReturn001
      try create command with incompatible values and expect TYPE_MISMATCH error in reply, but in many cases reply doesn't contain error and debuggee VM produce absolutely unexpected output.
      E.g. it is possible to return boolean instead of int, and this part of spec "For object values, there must be a widening reference conversion from the value's type to the return type" also isn't checked.

      For example debuggee VM run following thread:
          class TestThread
              implements Runnable
          {
              public void run()
              {
                  TestClass1 result = testMethod();
                  
                  log.display("Tested method result: " + result);
              }

              public TestClass1 testMethod()
              {
                  log.display("in test method");
                  
                  return new TestClass1();
              }

          }
      TestClass1 is empty class:

      class TestClass1
      {

      }

      Debugger set breakpont at line
                  log.display("in test method");
      and send ForceEarlyReturn command where 'value' is instance of java.lang.Object, reply for this command doesn't contain error code and debuggee thread after resuming produce output:
      debugee.stderr> Tested method result: java.lang.Object@a9c09e
      So, it is possible with ForceEarlyReturn return values of incompatible types.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                jbachorik Jaroslav BachorĂ­k
                Reporter:
                sboikovsunw Semen Boikov (Inactive)
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Imported:
                  Indexed: