Debugger misbehaving in 7281

Hi there,

I'm experiencing strange things with the debugger in 7281. Step over commands
end up getting me in weird places for some debug sessions. For other cases,
I can "step over" a few more times after the method should have finished
(a very simple test with a few asserts) before the debugger finally ends
up disconnected from the VM.

Anybody else seeing this?

Thx,
Andrei


5 comments
Comment actions Permalink

Hi Adrei,
>Step over commands end up getting me in weird places for some debug sessions

What are these places?
Can this be reproduced with a simple example?


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


0
Comment actions Permalink

Hello Eugene,

The one I can easily replicate is the step over after the end of the method,
where I can press F8 three-four more times before the debugger exits.
A simple test I have for this is a unit test with a few asserts. The same
thing works ok in 7.0.3.

Best,
Andrei

EZ> Hi Adrei,
EZ>
>> Step over commands end up getting me in weird places for some debug
>> sessions
>>
EZ> What are these places?
EZ> Can this be reproduced with a simple example?


0
Comment actions Permalink

The one I can easily replicate is the step over after the end of the method, where I can press F8 three-four more times before the
debugger exits.


Why you consider this a bug? It allows you to step over caller's instructions as soon as you press step-over. In 7.0.3 there was a
heuristic implemented: "continue step operation until it is possible to find a source for the current location". Because of this
heuristic debugger continued stepping "automatically". But the heuristic appeared to be not useful, but sometimes harmful. For
example, when debugging application server with lots of threads such "auto-stepping" caused weird behaviour: threads got magically
"suspended" even if the user pressed "resume", or one could suddenly find himself in completely different context than was before
stepping. This is because step requests remained and suspended execution when the thread was serving another request. We had to
remove the heuristic which made things more predictable.

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


0
Comment actions Permalink

Let's continue the discussion here:
http://www.jetbrains.net/jira/browse/IDEA-18062


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


0
Comment actions Permalink

Hello Eugene,

>>
EZ> Why you consider this a bug?

Well, I find it confusing, to start with. I understand your argument below
(even though I haven't experienced the problems you mention), but the new
behaviour does not properly allign with what I expect to see. I'm on the
last line of a method, I click F8, I expect to end up outside of that method.
Right now I have to press F8 several times (I counted 8 at some point) before
I end up where I expect.

Based on what you say, if any sort of logic gets interposed between the caller
and callee in my code, I would end up having to step over multiple times
before I get in the caller context, right? For a typical ejb invocation,
stepping out of the bean method would not get me to the caller right away,
but stay in limbo for a few more steps? Basically, step over on the last
line and step out are not the same thing? Or would the step out change behaviour
as well (I haven't tested it)?

Thx,
Andrei


EZ> It allows you to step over caller's
EZ> instructions as soon as you press step-over. In 7.0.3 there was a
EZ> heuristic implemented: "continue step operation until it is possible
EZ> to find a source for the current location". Because of this
EZ> heuristic debugger continued stepping "automatically". But the
EZ> heuristic appeared to be not useful, but sometimes harmful. For
EZ> example, when debugging application server with lots of threads such
EZ> "auto-stepping" caused weird behaviour: threads got magically
EZ> "suspended" even if the user pressed "resume", or one could suddenly
EZ> find himself in completely different context than was before
EZ> stepping. This is because step requests remained and suspended
EZ> execution when the thread was serving another request. We had to
EZ> remove the heuristic which made things more predictable.
EZ>


0

Please sign in to leave a comment.