IDEA Debugging stack frame unavailable

It appears that it might be that this only occurs when using the "pause" button to stop the program.

On 2007-06-15 00:02:47 +0400, Jason Winnebeck <no_reply@jetbrains.com> said:

When debugging under IDEA Selena #7016 I get a lot of variables that
cannot be evaluated -- it just says "stack frame unavailable." Is there
a setting I should be using to allow the debugger to see this
information? I tried disabling JIT thinking that optimization had
something to do it, but didn't see any effect. Google search suggest it
may be related to threads not suspended but I cannot find the "suspend
all threads" button that used to exist in the IDEA debugger.

You most probably get this "stack frame unavailable" message when
pausing VM with a pause button. To be able to use full debugger
abilities your debbugge instance must be stopped at breakpoint first.

I'm seeing this, too. I don't recall this being a problem before, so I'm confused by your statement.

Max is right - this has always been like this. The JPDA's limitation is that in order to be able to evaluate methods in some
thread's context, the thread must be paused as a result of some breakpoint request. When you pause VM with "pause" button, this
condition is not true - JPDA doesn't consider this a "breakpoint request". Thus any debugger features that rely on calling methods
(toString view, alternate collection views) cannot work.
I think in such cases debugger views can automatically switch in default mode to show the tree anyway without showing 'toString()'
and similat stuff.... This is planned to implement soon.

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

BTW, I still have an issue with the "Smart Step Into" functionality of the debugger:
Assume that you have a line of code like this:

You use smart stepping to step into the "inner" method, y.bar(). After you get back to the above line, when you invoke smart stepping into again, IDEA will offer you both y.bar() and x.foo() again, even though y.bar() has already been executed. (Choosing it again will simply cause the currently debugged line to advance).
I think that the list of stepping targets should only include the ones that are actually available. Is this possible, or is the current behavior also due to a JPDA limitation?

Regards,
Jens

>I think that the list of stepping targets should only include the ones that are actually available. Is this possible, or is the
>current behavior also due to a JPDA limitation?

Unfortunately, we cannot predict the execution path with JPDA, neither we can track previously executed instructions. Every time the
target VM is paused (even while stepping) you see current "execution snapshot". So IDEA suggests targets basing only on static code
analysis.

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

Thanks, so it seems that pausing is the reason for the limited debugger information. For some reason I couldn't mark "helpful" or "correct" on some posts I think it is because they are IDEA developers?