This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Build: NetBeans IDE Dev (Build 200810011401) VM: Java HotSpot(TM) Client VM, 11.0-b15, Java(TM) SE Runtime Environment, 1.6.0_10-rc2-b31 OS: Windows XP, 5.1, x86 User Comments: wobster: Looking at contents of array in debugger then switching focus to editor Stacktrace: java.lang.IndexOutOfBoundsException: from = -1 at org.netbeans.modules.debugger.jpda.models.JPDAThreadImpl.getCallStack(JPDAThreadImpl.java:432) at org.netbeans.modules.debugger.jpda.models.JPDAThreadImpl.getCallStack(JPDAThreadImpl.java:383) at org.netbeans.modules.debugger.jpda.ui.models.DebuggingTreeModel.computeChildren(DebuggingTreeModel.java:142) at org.netbeans.modules.debugger.jpda.ui.models.CachedChildrenTreeModel.getChildren(CachedChildrenTreeModel.java:74) at org.netbeans.spi.viewmodel.Models$DelegatingTreeModel.getChildren(Models.java:1202) at org.netbeans.modules.debugger.jpda.ui.models.DebuggingMonitorModel.getChildren(DebuggingMonitorModel.java:199)
Created attachment 71114 [details] stacktrace
Maybe ThreadReference.frameCount() returned -1 ? I'll check the JDI sources...
Still not able to get JDK sources due to https://jdk6.dev.java.net/issues/show_bug.cgi?id=24 I guess that ThreadReference.frameCount() can return -1 in some situation, even though it's not documented. This is expected to be a rare case and will hopefully be fixed in future versions of JDI.
ThreadReference.frameCount() can return -1 due to some race-condition. That should be fixed in upcoming JDK 1.6.0_11. However, the race-condition is triggered by unsynchronized threading of NetBeans debugger. That is to be fixed in NetBeans 7.0.
Build: NetBeans IDE 6.5 (Build 200811100001) VM: Java HotSpot(TM) Client VM, 11.0-b15, Java(TM) SE Runtime Environment, 1.6.0_10-b33 OS: Windows XP, 5.1, x86 User Comments: Stacktrace: java.lang.IndexOutOfBoundsException: from = 0, to = -1, frame count = 33 at org.netbeans.modules.debugger.jpda.models.JPDAThreadImpl.getCallStack(JPDAThreadImpl.java:442) at org.netbeans.modules.debugger.jpda.models.JPDAThreadImpl.getCallStack(JPDAThreadImpl.java:383) at org.netbeans.modules.debugger.jpda.ui.models.DebuggingTreeModel.computeChildren(DebuggingTreeModel.java:141) at org.netbeans.modules.debugger.jpda.ui.models.CachedChildrenTreeModel.getChildren(CachedChildrenTreeModel.java:74) at org.netbeans.spi.viewmodel.Models$DelegatingTreeModel.getChildren(Models.java:1202) at org.netbeans.modules.debugger.jpda.ui.models.DebuggingMonitorModel.getChildren(DebuggingMonitorModel.java:199)
Created attachment 75133 [details] stacktrace
Should be fixed by synchronized access to call stack in changeset: 113879:d55e6d13f88f http://hg.netbeans.org/main/rev/d55e6d13f88f (Please note that this fix is not applicable to 6.5 without issue #156368.)
The issue hasn't passed the nomination process for 65patch2 by cut-off date. It has been moved to 65patch3.
Integrated into 'main-golden', will be available in build *200901160201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/d55e6d13f88f User: mentlicher@netbeans.org Log: #149067 and #150472 - Stack retrieval is synchronized under the read lock. That should solve IndexOutOfBoundsExceptions caused by asynchronous access.
The status whiteboard "65fixes4-candidate" has been removed. At this time our proactive patches for the NetBeans 6.5.x IDE have concluded. If you own a Sun service plan contract for NetBeans, you may wish to contact Sun Service http://www.sun.com/contact/support.jsp to request a fix via the product defect escalation process. For more information on purchasing a Sun service plan contract for NetBeans, refer to the service plan item "Sun Software Service Plans (S3P) for Developers" in the Sun Service table found on our NetBeans Support Resources page http://www.netbeans.org/kb/support.html
Verified ... and Closing all issues resolved into NetBeans 6.7 and earlier.