Re: JVMTI_ERROR_INVALID_SLOT error after using AdviceAdapter.onMethodEnter

On 2/7/2018 11:10 AM, Haasip Satang wrote:
> Hi all,
> 
> I'm facing the issue that after weaving in a call to a static void method (no parameters) I get a 
> JVMTI error when trying to get the local variables; "this" at slot 0 to be specific.

Static methods have no "this" - though the test() method does - which is what the local
variable table is telling you.  I gather that your static method (not shown) is calling
JVMTI to examine the locals of the test() method, right?  You need to be sure your
JVMTI code is examining the right frame, etc.  I have used techniques like this to
access locals using similar instrumentation, and (with rather earlier releases of
ASM) it worked fine.

> Without the JVMTI agent the code runs fine, so no verify errors, everything can be interpreted and 
> works as expected. Without the asm instrumentation the JVMTI agent works as well though. Just if 
> both agents are enabled after and the one line on method entry is woven in I start getting these 
> problems.

Well, I think all you are saying is that when you actually use JVMTI, things fail.
But as I said, I wonder if you are looking at the right stack frame.

> The generated byte code seems legit to me. The only difference I noticed is the start value of the 
> local var "this", which is not 0. The slot is ok though. Could this be a problem?
> 
>    protected void test() throws java.lang.Exception;
>      descriptor: ()V
>      flags: ACC_PROTECTED
>      Code:
>        stack=0, locals=1, args_size=1
>           0: invokestatic  #178                // Method test/Tracer.methodEntry:()V
>           3: return
>        LocalVariableTable:
>          Start  Length  Slot  Name   Signature
>              3       1     0  this   Ltest/Test;    //  <-- is that the problem? If so how to around 
> this?
>        LineNumberTable:
>          line 56: 3
>      Exceptions:
>        throws java.lang.Exception
> 
> ASM version 5.0.4

I think that the local variable table originally came from the compiler, and that its
main purpose is to assist debuggers.  The original bytecode begins now at bytecode
number 3, so the LVT (and line number table) have been properly adjusted.  I don't
think JVMTI looks at any of this - it knows the stack frame layout and goes in and
grabs what you ask for.  JVMTI should work whether or not you have an LVT.

Perhaps you could/should share your code that calls into JVMTI, Java and/or C/C++?

Regards - Eliot Moss


-- 
You receive this message as a subscriber of the [email protected] mailing list.
To unsubscribe: mailto:[email protected]
For general help: mailto:[email protected]?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws