Wish: identify different object instances in the debug frame toolwindow

The new (detachable) frame toolwindow is great. And it assisted me greatly with identifying recursive calls and showing the debug markers.

I have a suggestion, which would make it even better - provide a way to identify an object instance in the frame window, i.e. the Variables view displays the hashCode.

I was debugging a crazy recursion with concurrent threads recently (don't ask even ;), and that one feature would've saved me many pains. Otherwise I can't tell the difference without putting a marker, but markers do not persist (naturally) between debug sessions.

Andrew

10 comments
Comment actions Permalink

On 2007-03-16 03:42:28 +0300, Andrew Perepelytsya
<no_reply@jetbrains.com> said:

The new (detachable) frame toolwindow is great. And it assisted me
greatly with identifying recursive calls and showing the debug markers.

I have a suggestion, which would make it even better - provide a way to
identify an object instance in the frame window, i.e. the Variables
view displays the hashCode.

I was debugging a crazy recursion with concurrent threads recently
(don't ask even ;), and that one feature would've saved me many pains.
Otherwise I can't tell the difference without putting a marker, but
markers do not persist (naturally) between debug sessions.

Andrew



Right click - mark object?

0
Comment actions Permalink

Right click - mark object?


Max, there are 2 problems with this approach:

1. Markers are not persisted across sessions. If I have to run a complex (otherwise why would I need a debugger?) scenario many times, I have to do it for each session. And I need to mark more than one object. Having an instance identifier like the Variables window has would be very convenient, while markers have their use-case.

2. F11 shortcut does not work in many toolwindows, though it's available through a right-click menu. AFAIR, it works only in Variables.

0
Comment actions Permalink

On 2007-03-16 19:39:29 +0300, Andrew Perepelytsya
<no_reply@jetbrains.com> said:

>> Right click - mark object?
>>


Max, there are 2 problems with this approach:

1. Markers are not persisted across sessions. If I have to run a
complex (otherwise why would I need a debugger?) scenario many times, I
have to do it for each session. And I need to mark more than one
object. Having an instance identifier like the Variables window has
would be very convenient, while markers have their use-case.

2. F11 shortcut does not work in many toolwindows, though it's
available through a right-click menu. AFAIR, it works only in Variables.


1. There's no way to persist object identity between JVM runs (or I
completely misunderstood what you're asking for.

2. What other places you'd like to have 'Mark Object' enabled in?

0
Comment actions Permalink


1. There's no way to persist object identity between
JVM runs (or I
completely misunderstood what you're asking for.


Absolutely true, no surprises here ;) I just want some object identity displayed next to the entry in the call frame (frames toolwindow).

2. What other places you'd like to have 'Mark Object'
enabled in?


I often missed it in the frames toolwindow - always had to jump to that stack frame, switch to Variables and put a marker on 'this'. After that it's displayed in Frames. Any chance to reduce the number of steps?

I hope this screenshot will help: http://mule.mulesource.org/jira/secure/attachment/10844/10844_1280_new_instance_1.gif

Note how the method entry is identified on the right with black markers (cool feature, btw ;) And how the bug was hidden until after I put debug markers to find out that I'm not operating with the same instance (strategy1 and strategy2 markers). A problem like this could've been identified earlier, had the identity been exposed in the Frames toolwindow.

Hope this helps,
Andrew

0
Comment actions Permalink

On 2007-03-17 01:41:37 +0300, Andrew Perepelytsya
<no_reply@jetbrains.com> said:

>>
>> 1. There's no way to persist object identity between
>> JVM runs (or I
>> completely misunderstood what you're asking for.
>>


Absolutely true, no surprises here ;) I just want some object identity
displayed next to the entry in the call frame (frames toolwindow).

>> 2. What other places you'd like to have 'Mark Object'
>> enabled in?


I often missed it in the frames toolwindow - always had to jump to that
stack frame, switch to Variables and put a marker on 'this'. After that
it's displayed in Frames. Any chance to reduce the number of steps?

I hope this screenshot will help:
http://mule.mulesource.org/jira/secure/attachment/10844/10844_1280_new_instance_1.gif


Note


how the method entry is identified on the right with black markers
(cool feature, btw ;) And how the bug was hidden until after I put
debug markers to find out that I'm not operating with the same instance
(strategy1 and strategy2 markers). A problem like this could've been
identified earlier, had the identity been exposed in the Frames
toolwindow.

Hope this helps,
Andrew


Correct me if I wrong: you suggest automatically mark all the
instances involved in certain stack frame so one could identify, where
execution is delegated from one instance to another?

Sounds like good idea, we'll investigate if this won't consume to many
resources to display.

0
Comment actions Permalink

Yes, that would be yet another way to achieve the same effect. Do your magic :)

0
Comment actions Permalink

Correct me if I wrong: you suggest automatically mark all the
instances involved in certain stack frame so one could identify, where
execution is delegated from one instance to another?


i think i'll need an example. what does "where execution is delegated from one instance to another" mean?

0
Comment actions Permalink

E.g. in concurrent programming one moment you call a method on one instance, the next moment the same method call is executed on the other instance of the same class. I think the easiest example to grok is when working with any kind of a pool.

Check the screenshot, it depicts the problem nicely, though it was not a pool ;)

0
Comment actions Permalink

yes, i know these confusing situations. my suggestion would be to nest a tabbedpane inside the editor instead of showing the code directly, offering one tab per thread (showing the thread's name in a tab) that is currently inside a method of the opened class. this way, you could step through the class in multiple threads at the same time without loosing the context.

Message was edited by:
HamsterofDeath

0

Please sign in to leave a comment.