Re: JVMTI_ERROR_INVALID_SLOT error after using AdviceAdapter.onMethodEnter

Found the problem. It is indeed caused by the wrong start for the local
variable "this" at slot 0. As you also pointed out the original byte code
now starts at position 3.

So it seems that JVMTI does consider those values as well, which makes
sense I guess as debuggers usually are build on top of JVMTI (at least I
wouldn't know another way).

The problem in my app is that the jvmti agent sets a breakpoint to the
start at the method --> position 0. Since it is an instance method usually
the "this" variable should be available at slot 0 at this point already.
After the instrumentation, however, the visibility for "this" only starts
at instruction 3. Therefore the agent cannot access "this" yet although
being in the right stack frame.

I worked around this in a hacky way now by patching the offset (the
"position" field of the label) to 0 in visitLocalVariable if the name is
"this" and offset != 0. This way it works.

Am just wondering if there isn't a cleaner way to do this. While the byte
code is perfectly valid for the JVM in Java we would never get an instance
method where "this" is not available at positon 0 already.
What do you think?

Thanks
Haasip

BTW: I meant to say I am adding an INVOKESTATIC instruction (a call to a
static void method) to an instance method (test()), sorry if that was
confusing.


Am 08.02.2018 00:06 schrieb "Eliot Moss" <[email protected]>:

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


-- 
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