Bug 141061

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

*** Issue 141687 has been marked as a duplicate of this issue. ***

Reopening - reproduced in NetBeans IDE Dev (Build 20090121074310)
http://statistics.netbeans.org/exceptions/detail.do?id=79656

This issue has already 10 duplicates 
see http://statistics.netbeans.org/exceptions/detail.do?id=79656

*** Issue 157042 has been marked as a duplicate of this issue. ***

*** Issue 157363 has been marked as a duplicate of this issue. ***

It's hopefully finally fixed in changeset:   116739:bf9693a8a6c4
http://hg.netbeans.org/main/rev/bf9693a8a6c4

Integrated into 'main-golden', will be available in build *200902180201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/bf9693a8a6c4
User: mentlicher@netbeans.org
Log: #141061 - Prevent from InvalidStackFrameException: Thread has been resumed thrown from Evaluator. Also, we attach the expression to the exception so that we can better identify the problems in the future.

Still reproducible. See http://statistics.netbeans.org/analytics/detail.do?id=145132. There are 7 duplicates with build
number newer than 200902180201.

*** Issue 158508 has been marked as a duplicate of this issue. ***

*** Issue 159245 has been marked as a duplicate of this issue. ***

*** Issue 160624 has been marked as a duplicate of this issue. ***

It would be valuable to have some steps how to reproduce this. But I understand that since this is a random issue, 100%
reproducible steps may not exist.

*** Issue 162338 has been marked as a duplicate of this issue. ***

*** Issue 162339 has been marked as a duplicate of this issue. ***

Build: NetBeans IDE 6.5 (Build 200811100001)
VM: Java HotSpot(TM) Client VM, 11.0-b15, Java(TM) Platform, Standard Edition for Business, 1.6.0_10-b33
OS: SunOS, 5.11, x86

User Comments: 
debugging a java application.

Stacktrace: 
com.sun.jdi.InvalidStackFrameException: Thread has been resumed
        at com.sun.tools.jdi.StackFrameImpl.validateStackFrame(StackFrameImpl.java:62)
        at com.sun.tools.jdi.StackFrameImpl.location(StackFrameImpl.java:71)
        at org.netbeans.modules.debugger.jpda.expr.TreeEvaluator.indexOf(TreeEvaluator.java:150)
        at org.netbeans.modules.debugger.jpda.expr.TreeEvaluator.evaluate(TreeEvaluator.java:105)
        at org.netbeans.modules.debugger.jpda.JPDADebuggerImpl.evaluateIn(JPDADebuggerImpl.java:770)
        at org.netbeans.modules.debugger.jpda.breakpoints.BreakpointImpl.evaluateConditionIn(BreakpointImpl.java:677)

Created attachment 79928 [details]
stacktrace

This issue already has 53 duplicates 
see http://statistics.netbeans.org/exceptions/detail.do?id=79656

This issue already has 53 duplicates 
see http://statistics.netbeans.org/exceptions/detail.do?id=79656

Very similar to issue #158750.

*** Issue 158799 has been marked as a duplicate of this issue. ***

This should have been actually fixed together with issue #158750 in changeset:   137391:b8f16f4a60fa
http://hg.netbeans.org/main/rev/b8f16f4a60fa

I got the exception several times during the last two days.

I guess it is caused by a rather long condition expression on one of the line breakpoints (see http://statistics.netbeans.org/analytics/exception.do?id=308603 for details). The conditional line breakpoint was set on the first line of constructor of class java.util.IdentityHashMap(int). I got the exception when I invoked action Team > Find Issues... in the remote instance (the one being debugged) of NetBeans.

Summary of the breakpoint's properties:
- conditional line breakpoint
- condition: (expectedMaxSize == 2) || (expectedMaxSize == 3) || (expectedMaxSize == 5) || (expectedMaxSize == 10) || (expectedMaxSize == 11) || (expectedMaxSize == 21) || (expectedMaxSize == 42) || (expectedMaxSize == 43) || (expectedMaxSize == 85) || (expectedMaxSize == 170) || (expectedMaxSize == 171) || (expectedMaxSize == 341) || (expectedMaxSize == 682) || (expectedMaxSize == 683) || (expectedMaxSize == 1365) || (expectedMaxSize == 2730) || (expectedMaxSize == 2731) || (expectedMaxSize == 5461) || (expectedMaxSize == 10922) || (expectedMaxSize == 10923) || (expectedMaxSize == 21845) || (expectedMaxSize == 43690) || (expectedMaxSize == 43691) || (expectedMaxSize == 87381) || (expectedMaxSize == 174762) || (expectedMaxSize == 174763) || (expectedMaxSize == 349525) || (expectedMaxSize == 699050) || (expectedMaxSize == 699051) || (expectedMaxSize == 1398101) || (expectedMaxSize == 2796202) || (expectedMaxSize == 2796203) || (expectedMaxSize == 5592405)
- set on line IdentityHashMap:203  (first line of constructor IdentityHashMap(int) in JDK 6u18 b05)
- suspend mode: No thread (continue)
- print text: expected max. size = {=expectedMaxSize}

Because the exception's properties are rather exceptional, I lower the priority to P3.

*** Bug 177627 has been marked as a duplicate of this bug. ***

Created attachment 99012 [details]
stacktrace

*** Bug 173524 has been marked as a duplicate of this bug. ***

*** Bug 177892 has been marked as a duplicate of this bug. ***

It should be finally fixed by changeset:   174465:ed9146168c0c
http://hg.netbeans.org/main/rev/ed9146168c0c
I've tested it on the long condition on the breakpoint in IdentityHashMap.

Integrated into 'main-golden', will be available in build *201007180001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/ed9146168c0c
User: mentlicher@netbeans.org
Log: #141061, #188345 Refuse to perform code evaluation if the thread is not suspended.

Integrated into 'main-golden', will be available in build *201007290001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/dfccc159581f
User: mentlicher@netbeans.org
Log: #187533, #188732 Cache the thread stack depth and assure that stack frames are retrieved only for suspended threads (thus preventing from IncompatibleThreadStateException. Also suspendedNoFire is set to false when a thread is resumed. This should also prevent from bug #141061.

http://statistics.netbeans.org/analytics/exception.do?id=431912
reproducing in dev

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.

Unfortunately, even though I've tried hard, I could not reproduce this.
If you have some steps to reproduce, please provide them.
Since the exception should not break anything, moving to P4.

Created attachment 105747 [details]
stacktrace

Created attachment 109917 [details]
stacktrace

279 dups ... and still coming, even from Nb 7.0.1

Not explored yet what makes the thread resumed.
Any steps that will help us to reproduce this would help.

(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.

Integrated into 'main-golden'
Changeset: http://hg.netbeans.org/main-golden/rev/1700174456fd
User: mentlicher@netbeans.org
Log: #141061 Further debugging added to be able to better identify the InvalidStackFrameException problem. Also the locking is fixed in CallStackFrameImpl.

Created attachment 116184 [details]
stacktrace

Created attachment 116394 [details]
stacktrace

debugging java file

Created attachment 116421 [details]
stacktrace

debugging java file

Integrated into 'main-golden', will be available in build *201203090400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/c9fc6f78210f
User: mentlicher@netbeans.org
Log: #141061: Attach a more detailed message to InvalidStackFrameException.

Created attachment 116657 [details]
stacktrace

Debugging NetBeans codebase.

Created attachment 116725 [details]
stacktrace

Created attachment 116726 [details]
stacktrace

Again, this looks like some awkward behavior of JDI.
I've managed to get this exception on a regular basis after application of this patch:

diff -r d5621170a2d2 debugger.jpda/src/org/netbeans/modules/debugger/jpda/expr/EvaluationContext.java
--- a/debugger.jpda/src/org/netbeans/modules/debugger/jpda/expr/EvaluationContext.java	Mon Mar 26 14:19:59 2012 +0200
+++ b/debugger.jpda/src/org/netbeans/modules/debugger/jpda/expr/EvaluationContext.java	Mon Mar 26 14:54:35 2012 +0200
@@ -154,6 +154,15 @@
 
     public StackFrame getFrame() {
         try {
+            ThreadReference tr;
+            tr = frame.thread();
+            // Test:
+            logger.config("Test thread state:       initial: "+JPDAThreadImpl.getThreadStateLog(tr));
+            frame.thread().suspend();
+            logger.config("Test thread state: after suspend: "+JPDAThreadImpl.getThreadStateLog(tr));
+            frame.thread();
+            frame.thread().resume();
+            logger.config("Test thread state:  after resume: "+JPDAThreadImpl.getThreadStateLog(tr));
             frame.thread();
         } catch (InvalidStackFrameException isex) {
             // Update the stack frame


This patch does absolutely NOTHING. It just suspends an already suspended thread and then resumes it to make it just supended with suspend count == 1 again.
Doing only this results in an invalidation of the stack frame. :-(

Now we have at least some indication about the nature of this "bug".

Created attachment 117642 [details]
stacktrace

hitting a breakpoint

Created attachment 118794 [details]
stacktrace

Point the cursor over a parameter to show its value while debugging a java source.

*** Bug 210112 has been marked as a duplicate of this bug. ***

14 duplicates. 378 reports.

Yes, no wonder when JDI is so fragile.
I hope to have some solution soon. It will be risky, but something must be done.

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.

Integrated into 'main-golden', will be available in build *201205010400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/e2109c2f87de
User: mentlicher@netbeans.org
Log: #141061: Minimizing the chance that we work with invalid stack frames.