Re: JVMTI_ERROR_INVALID_SLOT error after using AdviceAdapter.onMethodEnter

I unfortunately can't use GetLocalInstance as I have a generic piece of
code that also needs to access potential arguments .
Will check if there is a cleaner way to update the LVT, otherwise I will
just apply the same hack.

Alternatively I will check what effects moving the breakpoint to a
different instruction would have (e.g. position 3 instead of 0). The
obvious problem I see is that this position will always need to be
readjusted whenever some changes are done in the instrumentation that might
lead to a change in offset again. Probably the hacky approach is less error
prone / requires less maintenance.

Will let you know if I find a better way. Thanks for your quick replies :)

2018-02-08 11:46 GMT+01:00 Eliot Moss <[email protected]>:

> On 2/8/2018 5:31 AM, Haasip Satang wrote:
>
>> 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?
>>
>
> Here's a wondering ....
>
> I had a look at the JVMTI documentation and there are several relevant
> functions, but notable:
>
> jvmtiError GetLocalObject(jvmtiEnv* env, jthread thread, jint depth, jint
> slot, jobject* value_ptr)
>
> and
>
> jvmtiError GetLocalInstance(jvmtiEnv* env, jthread thread, jint depth,
> jobject* value_ptr)
>
> The docs indicate that GetLocalInstance behaves a bit differently from
> GetLocalObject(..., 0, ...),
> and it might make a difference here.  (Now if the method took arguments,
> and you wanted one of those - which *should* be available from the start -
> you might have to make sure the LVT is updated.)
>
> Regards - EM
>
>
> --
> 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