I'm getting many frequent exceptions while debugging just while moving the caret around in the editor (attempts to do
balloon evaluation / tooltip evaluation I think).
This is on OSX. I'm seeing a lot of exceptions while trying to debug.
Build: NetBeans IDE Dev (Build 080721)
VM: Java HotSpot(TM) Client VM, 1.5.0_13-119, Java(TM) 2 Runtime Environment, Standard Edition, 1.5.0_13-b05-237
OS: Mac OS X, 10.5.4, i386
User comments: Just single stepping
STACKTRACE: (first 10 lines)
com.sun.jdi.InvalidStackFrameException: Thread has been resumed
at com.sun.tools.jdi.StackFrameImpl.validateStackFrame(StackFrameImpl.java:61)
at com.sun.tools.jdi.StackFrameImpl.location(StackFrameImpl.java:70)
at org.netbeans.modules.debugger.jpda.expr.EvaluatorVisitor.getIdentifierByName(EvaluatorVisitor.java:1172)
at org.netbeans.modules.debugger.jpda.expr.EvaluatorVisitor.visitIdentifier(EvaluatorVisitor.java:1238)
at org.netbeans.modules.debugger.jpda.expr.EvaluatorVisitor.visitIdentifier(EvaluatorVisitor.java:172)
at com.sun.tools.javac.tree.JCTree$JCIdent.accept(JCTree.java:1689)
at com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:49)
at org.netbeans.modules.debugger.jpda.projects.EditorContextImpl.parseExpression(EditorContextImpl.java:1465)
at sun.reflect.GeneratedMethodAccessor268.invoke(GeneratedMethodAccessor268.java:0)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

Hopefully this is also fixed in changeset: 91617:336b808f2fcf
The stack frames are refreshed when they become obsolete, thus invalid stack frame should not be given to the evaluation
process. Please verify.
http://hg.netbeans.org/main/rev/336b808f2fcf

From the exception reports we can see that the exception occurs after Continue.
Therefore there's likely some missing synchronization when Continue resumes threads...
The exception seems to be non-destructive.

(In reply to comment #37)
> Not explored yet what makes the thread resumed.
> Any steps that will help us to reproduce this would help.
I had a particular debugging scenario where it was fairly reproducible. Unfortunately I cannot remember it now. If I bump into it again I will let you know.

I've added some logging in changeset: 201155:1700174456fd
Also, I've found one place with a bad locking. I'm not sure if this has caused this problem or not, the problem is that the exception is just a symptom of some bad state, but it's not clear how we got to this bad state.
http://hg.netbeans.org/main/rev/1700174456fd
I'm resolving as fixed for now, if the problem reappears, please report it through the Exceptions Reporter. That should include the newly added logging. Also, the steps that you did before the exception was thrown are welcomed, some test case would be great.

It should be mostly fixed by changeset: 220450:e2109c2f87de
http://hg.netbeans.org/main/rev/e2109c2f87de
I've found it very problematic to really assure, that the stack frame does not get invalidated at any time. If the target thread, that we perform the evaluation in, gets suspended in the backend (that can happen at any time and can not be prevented from), the thread might get suspended twice and we need to call "resume" on it, to reduce the suspend count to 1. This unfortunately invalidates the stack frame. I've submitted issue #211841 for this problem. It needs to be explored, if it's solvable.