0 Replies Latest reply on May 18, 2010 6:13 AM by 843810


      While writing an agent for generating an execution trace using JVMTI 1.1, I got an error JVMTI_ERROR_INVALID_SLOT. I tried to figure out what causes the problem, but I only got some guesses about when that can happen.

      I know that instrumentation gives better performance, but I need all arguments and stack inspection, which is not what instrumentation can provide, as of my best knowledge. In my MethodEntry handler, I wanted to get the values of arguments; so, I wrote C++ code as follows:

      for each parameter specified by the signature of the invoked method
      if (the parameter is of object type)
      jobject value;
      jvmti->GetLocalObject(thread, 0, slot, &value);
      else if (the parameter is of int type)
      jint value;
      jvmti->GetLocalInt(thread, 0, slot, &value);
      increase "slot" variable properly

      I set 0 for the second argument because I'm interested in the uppermost stack, and "slot" accordingly; e.g., increase by 1 for int type, but 2 for double type, etc. I really do not think I made mistakes in calculation.

      It seemed to work very well for my toy program, and many other programs. However, the "GetLocalObject" returns JVMTI_ERROR_INVALID_SLOT for some arguments. For example, that error was raised while the constructor, (Ljunit/framework/TestResult;Ljunit/framework/TestCase;)V, of Ljunit/framework/TestResult$1; is being invoked. Accessing slot 1 using GetLocalObject() returned "invalid slot".

      Here's my first question. Is it right to call GetLocal*() function to retrieve arguments? My understanding is that "this" object is stored at slot 0, and all arguments are stored from slot 1. (If the method is static, arguments are stored from slot 0.) I assumed that I can calculate which slot corresponds to each argument from the signature and the fact that double/long takes two slots and others take one slot.

      If my understanding is correct, I really do not understand why I got that error. My program anticipates the exact type of each argument, and calls the proper GetLocal*() function. To double-check this, I also modified my code so that it tries every possible GetLocal*() function for each slot, but I still get the error.

      One thing I found out is that it seems the error occurs in constructors (mostly in nested classes). I have not seen that error in normal methods. I just assumed that constructors are just like normal non-static methods in that the slot 0 is filled with "this" object, which is the newly created object.

      Edited by: linjus on May 17, 2010 11:09 PM

      Edited by: linjus on May 17, 2010 11:10 PM

      Edited by: linjus on May 17, 2010 11:11 PM

      Edited by: linjus on May 17, 2010 11:12 PM