'this' is not available, in debugger variables window

Hi there,

What's the cause of that message? It shows up in debug mode, where I would
expect to see member variables. Is there a setting somewhere I messed up
with? Or is it a bug? Happens in both 7.0.4 and latest 7.0.5 EAP.

Thx,
Andrei


6 comments
Comment actions Permalink

Same for me...didnt consider it to be a bug though. But I could be wrong :)

0
Comment actions Permalink

The message appears when 'this' object cannot be determined from the context (current execution point).
Please describe your case in detail.

--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"

"Andrei Oprea" <andrei.oprea@rogers.com> wrote in message news:de739147b5ca8cb0958e388ac66@news.intellij.net...

Hi there,

>

What's the cause of that message? It shows up in debug mode, where I would expect to see member variables. Is there a setting
somewhere I messed up with? Or is it a bug? Happens in both 7.0.4 and latest 7.0.5 EAP.

>

Thx,
Andrei

>



0
Comment actions Permalink

Hello Eugene,

EZ> The message appears when 'this' object cannot be determined from the
EZ> context (current execution point).
EZ>
EZ> Please describe your case in detail.
EZ>

Nothing fancy. I'm debugging some code and, while inside a method, instead of seeing instance variables I get that message. The local variables are OK, and assigning the instance variable to a local one allows me to see its value, but both the variables view (and the watches, if I try that) show me the message.

See the attached screenshot for an example.

Now, we do have an aspectJ based mocking framework that allows us to replace some methods when we need to (and I think wraps all the method calls in around advices, just so it can short circuit them when needed), if that's relevant at all.

Best,
Andrei



Attachment(s):
thisNotAvailable.png
0
Comment actions Permalink

In the screenshot I see the current execution point is inside around advice implementation. Looks like this is a static method:
notice the node "static" in the Variables tab. In static context 'this' is not available indeed. In general, debugger's behaviour
depends on the way the instrumentation is implemented in AspectJ (whether they use static or member methods to implement certain
features, etc). The way debug info is updated after instrumentation may affect debugger's behaviour too. For example, inserting some
instructions at the beginning of the method and not updating variable table will make method parameters including 'this' reference
not visible to debugger at the very begining of the method while you are stepping over generated instructions.

--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"


"Andrei Oprea" <andrei.oprea@rogers.com> wrote in message news:de739147b73a8cb0a1fe023ffea@news.intellij.net...
Hello Eugene,

EZ> The message appears when 'this' object cannot be determined from the
EZ> context (current execution point).
EZ>
EZ> Please describe your case in detail.
EZ>

Nothing fancy. I'm debugging some code and, while inside a method, instead of seeing instance variables I get that message. The
local variables are OK, and assigning the instance variable to a local one allows me to see its value, but both the variables view
(and the watches, if I try that) show me the message.

See the attached screenshot for an example.

Now, we do have an aspectJ based mocking framework that allows us to replace some methods when we need to (and I think wraps all the
method calls in around advices, just so it can short circuit them when needed), if that's relevant at all.

Best,
Andrei


0
Comment actions Permalink

Hi Eugene,

Sorry, but I have to reopen this discussion. I had a chance to talk to the developer who put the mocking stuff in place and I'm not sure how things could be done differently, so IDEA can understand the context, as I don't really understand what throws it off.

Here are some more details about the observed behaviour:
- if a breakpoint is placed on the first line of the method, it will be hit twice. The first time, the instance variables are avaialbe and the call stack shows we're in the context of the original method. The second time, 'this' is not available anymore and the method is the around body, as seen in the image attached to the previous post
- 'this' remains unavailable for the whole method body after that, when stepping over and reaching other places in the method body
- as mentioned, I fail to see where the static context comes from. If I expand it, I get a list of the around advices traversed while getting to this point (all the methods have around advices intercepting them, in case they need to be skipped). But I don't see why the object instance is not available while inside the around body...
- Eclipse works OK with this setup, so there must be a way around it

I can provide you with the implementation for the aspect that takes care of the mocking, if you thing that could help.

Best,
Andrei

jeka wrote:

In the screenshot I see the current execution point is inside around advice implementation. Looks like this is a static method:
notice the node "static" in the Variables tab. In static context 'this' is not available indeed. In general, debugger's behaviour
depends on the way the instrumentation is implemented in AspectJ (whether they use static or member methods to implement certain
features, etc). The way debug info is updated after instrumentation may affect debugger's behaviour too. For example, inserting some
instructions at the beginning of the method and not updating variable table will make method parameters including 'this' reference
not visible to debugger at the very begining of the method while you are stepping over generated instructions.


--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"


0
Comment actions Permalink

There's an issue with Hugo library by Jake Wharton. Please take a look to https://github.com/JakeWharton/hugo/issues/128. I faced this issue too. I had to remove @DebugLog annotation of the method I was debugging.

0

Please sign in to leave a comment.