Comment 1 Samantha Chan 2007-02-06 17:46:29 EST

Get similar exceptions without involving import.
I get them from moving and copying breakpoints around.

org.eclipse.swt.SWTException: Widget is disposed
	at org.eclipse.swt.SWT.error(SWT.java:3478)
	at org.eclipse.swt.SWT.error(SWT.java:3401)
	at org.eclipse.swt.SWT.error(SWT.java:3372)
	at org.eclipse.swt.widgets.Widget.error(Widget.java:438)
	at org.eclipse.swt.widgets.Widget.checkWidget(Widget.java:376)
	at org.eclipse.swt.widgets.Widget.getData(Widget.java:464)
	at org.eclipse.jface.viewers.AbstractTreeViewer.getTreePathFromItem(AbstractTreeViewer.java:2694)
	at org.eclipse.jface.viewers.AbstractTreeViewer.internalGetWidgetToSelect(AbstractTreeViewer.java:1604)
	at org.eclipse.jface.viewers.AbstractTreeViewer.internalExpand(AbstractTreeViewer.java:1496)
	at org.eclipse.jface.viewers.AbstractTreeViewer.internalExpand(AbstractTreeViewer.java:1504)
	at org.eclipse.jface.viewers.AbstractTreeViewer.setSelectionToWidget(AbstractTreeViewer.java:2341)
	at org.eclipse.jface.viewers.AbstractTreeViewer.setSelectionToWidget(AbstractTreeViewer.java:2728)
	at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1339)
	at org.eclipse.jface.viewers.CheckboxTreeViewer.preservingSelection(CheckboxTreeViewer.java:371)
	at org.eclipse.jface.viewers.StructuredViewer.refresh(StructuredViewer.java:1395)
	at org.eclipse.jface.viewers.StructuredViewer.refresh(StructuredViewer.java:1354)
	at org.eclipse.debug.internal.ui.views.breakpoints.BreakpointsViewer.refresh(BreakpointsViewer.java:340)
	at org.eclipse.debug.internal.ui.views.breakpoints.BreakpointsContentProvider.reorganize(BreakpointsContentProvider.java:218)
	at org.eclipse.debug.internal.ui.views.breakpoints.BreakpointsContentProvider.propertyChange(BreakpointsContentProvider.java:228)
	at org.eclipse.debug.ui.AbstractBreakpointOrganizerDelegate$1.run(AbstractBreakpointOrganizerDelegate.java:110)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
	at org.eclipse.debug.ui.AbstractBreakpointOrganizerDelegate.fireCategoryChanged(AbstractBreakpointOrganizerDelegate.java:113)
	at org.eclipse.debug.internal.ui.views.breakpoints.BreakpointSetOrganizer.propertyChange(BreakpointSetOrganizer.java:147)
	at org.eclipse.ui.internal.AbstractWorkingSetManager$3.run(AbstractWorkingSetManager.java:361)
	at org.eclipse.ui.internal.AbstractWorkingSetManager.firePropertyChange(AbstractWorkingSetManager.java:367)
	at org.eclipse.ui.internal.AbstractWorkingSetManager.workingSetChanged(AbstractWorkingSetManager.java:390)
	at org.eclipse.ui.internal.WorkingSetManager.workingSetChanged(WorkingSetManager.java:161)
	at org.eclipse.ui.internal.AbstractWorkingSet.fireWorkingSetChanged(AbstractWorkingSet.java:119)
	at org.eclipse.ui.internal.WorkingSet.setElements(WorkingSet.java:215)
	at org.eclipse.debug.internal.ui.views.breakpoints.BreakpointSetOrganizer.removeBreakpoints(BreakpointSetOrganizer.java:448)
	at org.eclipse.debug.internal.ui.views.breakpoints.BreakpointOrganizerExtension.removeBreakpoints(BreakpointOrganizerExtension.java:190)
	at org.eclipse.debug.internal.ui.views.breakpoints.BreakpointsViewer.performDrag(BreakpointsViewer.java:239)
	at org.eclipse.debug.internal.ui.views.breakpoints.BreakpointsDragAdapter.dragFinished(BreakpointsDragAdapter.java:77)
	at org.eclipse.swt.dnd.DNDListener.handleEvent(DNDListener.java:44)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1097)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1121)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1106)
	at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:947)
	at org.eclipse.swt.dnd.DragSource.dragEnd(DragSource.java:335)
	at org.eclipse.swt.dnd.DragSource.DragEnd(DragSource.java:216)
	at org.eclipse.swt.internal.gtk.OS._gtk_main_do_event(Native Method)
	at org.eclipse.swt.internal.gtk.OS.gtk_main_do_event(OS.java:5574)
	at org.eclipse.swt.widgets.Display.eventProc(Display.java:1155)
	at org.eclipse.swt.internal.gtk.OS._g_main_context_iteration(Native Method)
	at org.eclipse.swt.internal.gtk.OS.g_main_context_iteration(OS.java:1468)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2903)
	at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2257)
	at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2221)
	at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2096)
	at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:456)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:289)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:451)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:101)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:146)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:106)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:76)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:354)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:169)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60)
	at java.lang.reflect.Method.invoke(Method.java:391)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:476)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:416)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1124)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1099)

Comment 2 Michael Rennie 2007-02-07 12:48:03 EST

This appears to be a viewer issue. We are asking to expand a breakpoint container (non-null element, not widget) to all levels, and it seems that in expandToLevel, the method internalExpand is returning a disposed widget which is not checked for in internalExpandToLevel...

passing over to UI for comment.

Comment 3 Boris Bokowski 2007-02-07 14:40:13 EST

Are you sure that the underlying tree is not disposed?  Do you check for that before calling expandToLevel() or refresh()?

Comment 4 Gerhard Schaber 2007-04-17 14:16:14 EDT

Hi!

It seems this is the same issue I got with the common viewer:
Thread [main] (Suspended (breakpoint at line 432 in Widget))	
	TreeItem(Widget).error(int) line: 432	
	TreeItem(Widget).checkWidget() line: 325	
	TreeItem(Widget).getData() line: 485	
	CommonViewer(AbstractTreeViewer).updateChildren(Widget, Object, Object[], boolean) line: 2490	
	CommonViewer(AbstractTreeViewer).internalRefreshStruct(Widget, Object, boolean) line: 1788	
	CommonViewer(TreeViewer).internalRefreshStruct(Widget, Object, boolean) line: 561	
	CommonViewer(AbstractTreeViewer).internalRefresh(Widget, Object, boolean, boolean) line: 1763	
	CommonViewer(AbstractTreeViewer).internalRefresh(Object, boolean) line: 1719	
	CommonViewer.internalRefresh(Object, boolean) line: 454	
	StructuredViewer$8.run() line: 1478	
	CommonViewer(StructuredViewer).preservingSelection(Runnable) line: 1333	
	CommonViewer(StructuredViewer).refresh(Object, boolean) line: 1476	
	CommonViewer.refresh(Object, boolean) line: 300	
	CommonViewer.refresh(Object) line: 401	
	CElementContentProvider$RefreshElement.refresh() line: 350	
	CElementContentProvider$1.run() line: 423	
	RunnableLock.run() line: 35	
	UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 123	
	Display.runAsyncMessages(boolean) line: 3650	
	Display.readAndDispatch() line: 3287	
	Workbench.runEventLoop(Window$IExceptionHandler, Display) line: 2337	
	Workbench.runUI() line: 2301	
	Workbench.access$4(Workbench) line: 2176	
	Workbench$4.run() line: 463	
	Realm.runWithDefault(Realm, Runnable) line: 289	
	Workbench.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 458	
	PlatformUI.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 149	
	UnifiedSWTSwingApplication(CopyOfIDEApplication).start(IApplicationContext) line: 104	
	UnifiedSWTSwingApplication.access$4(UnifiedSWTSwingApplication, IApplicationContext) line: 1	
	UnifiedSWTSwingApplication.start(IApplicationContext) line: 37	
	EclipseAppHandle.run(Object) line: 146	
	EclipseAppLauncher.runApplication(Object) line: 106	
	EclipseAppLauncher.start(Object) line: 76	
	EclipseStarter.run(Object) line: 356	
	EclipseStarter.run(String[], Runnable) line: 171	
	NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]	
	NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39	
	DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25	
	Method.invoke(Object, Object...) line: 585	
	Main.invokeFramework(String[], URL[]) line: 476	
	Main.basicRun(String[]) line: 416	
	Main.run(String[]) line: 1141	
	Main.main(String[]) line: 1116	

I guess the problem is around line 2489 in method
private void updateChildren(Widget widget, Object parent,
  Object[] elementChildren, boolean updateLabels) {
...
    items[i].dispose();
    if (i + 1 < items.length) {
    // The components at positions i+1 through
    // items.length-1 in the source array are copied into
    // positions i through items.length-2
    System.arraycopy(items, i + 1, items, i, items.length - (i+1));
  }
  numItemsToDispose--;

It seems that items.length stays the same while disposed widgets are removed. At the end of the array there are some dangling references to the same widget.

Example:
1. Widgets in the items array:
Widget A <= i
Widget B
Widget C

2. Widget B is disposed and removed (the rest of the array is moved forward in the items array)

3. Widgets in the items array:
Widget A
Widget C <= i
Widget C

4. Widget C may also be disposed and removed

5. Widget in the items array:
Widget A
Widget C (disposed)
Widget C (disposed) <= i

Comment 5 Boris Bokowski 2007-04-17 14:26:16 EDT

(In reply to comment #4)

Gerhard, your stack trace looks different - could you please file a separate bug? Thanks.

Marking this one as needinfo.

Comment 6 Gerhard Schaber 2007-04-17 14:59:30 EDT

Hi!

The last stacktrace before mine looks very similar to mine (coming from StructuredViewer.preserveSelection and refresh).

However, I created Bug #182809 for that issue.

Best regards,

   Gerhard

Comment 7 Sebastian Fuchs 2007-08-14 04:54:09 EDT

I had a similar exception when I implemented equals() and hashCode() by myself.
The methods' logic were ok but it seems, that even there were equals()-collisions.
When switching to default equals() and hashCode() everything is fine.

Maybe this bug is related to
Bug #195320
and
Bug #182809 ?


!ENTRY org.eclipse.ui 4 0 2007-08-14 10:45:46.933
!MESSAGE Unhandled event loop exception
!STACK 0
org.eclipse.swt.SWTException: Widget is disposed
	at org.eclipse.swt.SWT.error(SWT.java:3563)
	at org.eclipse.swt.SWT.error(SWT.java:3481)
	at org.eclipse.swt.SWT.error(SWT.java:3452)
	at org.eclipse.swt.widgets.Widget.error(Widget.java:432)
	at org.eclipse.swt.widgets.Widget.checkWidget(Widget.java:325)
	at org.eclipse.swt.widgets.Widget.getData(Widget.java:485)
	at org.eclipse.jface.viewers.AbstractTreeViewer.getTreePathFromItem(AbstractTreeViewer.java:2743)
	at org.eclipse.jface.viewers.AbstractTreeViewer.internalGetWidgetToSelect(AbstractTreeViewer.java:1642)
	at org.eclipse.jface.viewers.AbstractTreeViewer.internalExpand(AbstractTreeViewer.java:1537)
	at org.eclipse.jface.viewers.AbstractTreeViewer.setSelectionToWidget(AbstractTreeViewer.java:2390)
	at org.eclipse.ui.navigator.CommonViewer.setSelectionToWidget(CommonViewer.java:337)
	at org.eclipse.jface.viewers.AbstractTreeViewer.setSelectionToWidget(AbstractTreeViewer.java:2777)
	at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1375)
	at org.eclipse.jface.viewers.TreeViewer.preservingSelection(TreeViewer.java:378)
	at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1330)
	at org.eclipse.jface.viewers.StructuredViewer.refresh(StructuredViewer.java:1458)
	at org.eclipse.jface.viewers.ColumnViewer.refresh(ColumnViewer.java:514)
	at org.eclipse.ui.navigator.CommonViewer.refresh(CommonViewer.java:303)
	at org.eclipse.ui.navigator.CommonViewer.refresh(CommonViewer.java:401)
	at org.eclipse.jface.viewers.StructuredViewer.refresh(StructuredViewer.java:1390)
	at de.tragwerk.solution.projman.navigator.ProjmanContentProvider$2.propertyChange(ProjmanContentProvider.java:44)
	at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:339)
	at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:276)
	at de.tragwerk.core.bo.PropertyObject.firePropertyChange(PropertyObject.java:45)
	at de.tragwerk.solution.projman.modell.ProjectTree.fireElementsAddEvent(ProjectTree.java:77)

Comment 8 Boris Bokowski 2007-08-14 13:53:35 EDT

(In reply to comment #7)
> I had a similar exception when I implemented equals() and hashCode() by myself.

Interesting. Michael, could you see if you can find anything suspicious with equals() or hashCode() for breakpoint elements?

Comment 9 Sebastian Fuchs 2007-08-14 14:24:17 EDT

(In reply to comment #8)

> Interesting. Michael, could you see if you can find anything suspicious with
> equals() or hashCode() for breakpoint elements?
> 

Sorry Boris,

I had not got the bug title so far.

I used the the Common Navigator with my own business modell. That's what the equals() and hashCode() methods were for.

No relationsship to breakpoints, sorry.

But maybe it's a viewer problem ?

Sebastian

Comment 10 Boris Bokowski 2007-08-14 14:27:06 EDT

No need to apologize - I still think it is worth looking at equals() and hashCode() for breakpoints.  I'm sure Michael will assign the bug back to UI if this doesn't lead anywhere.

Comment 11 Curtis Windatt 2007-08-14 15:06:08 EDT

When the breakpoints view is organized by multiple categories there can be multiple elements in the viewer that are equal and have the same hashcode.

To reproduce the bug, we would typically use the Group By > Advanced... action and add most or all of the available groupings.  This can result in a hierarchy like the following:

File A
     Working Set A
          Line Breakpoints
               Breakpoint A
               Breakpoint B
File B
     Working Set A
          Line Breakpoints
               Breakpoint C
               Breakpoint D

In the above example, the Working Set A and Line Breakpoint categories appear twice in the view, but have the same equals/hashcode.

Comment 12 Curtis Windatt 2007-08-14 15:44:34 EDT

I wasn't able to reproduce the problem to test if changing the equals/hashcode would fix anything.

Comment 13 Boris Bokowski 2007-08-14 16:28:59 EDT

(In reply to comment #12)
> I wasn't able to reproduce the problem to test if changing the equals/hashcode
> would fix anything.

Did you have a look at the equals() and hashCode() implementations?  Any chance that a hash code of an element can change over time, or that equals() and hashCode() are not consistent as described in the Javadoc for Object.hashCode()?

Comment 14 Curtis Windatt 2007-08-14 17:11:11 EDT

Yes I looked at the implementation.  The breakpoint containers override the equals and hashcode methods.  The hashcode for a container is the hashcode of its 'category'.

Categories can be a variety of objects (and IAdaptable).  Depending on what groups are being shown, they can be of the type File,  Project, WorkingSetCategory, OtherBreakpointCategory.  WorkingSetCategory.hashCode asks the working set it represents for the hashcode.  OtherBreakpointCategory asks for the organizers hashcode, and the organizers use the default Object implementation.

I don't believe any of the methods break the hashcode contract (changing over time, etc.).  As I noted in comment #11, there will be different containers that share the same hashcode.

Comment 15 Michael Rennie 2007-08-29 16:24:43 EDT

The two bugs have the same underlying problem, that a disposed tree element is being accessed...

*** This bug has been marked as a duplicate of bug 184915 ***