Community
Participate
Working Groups
We are seeing a hang when deleting a project under the "Other Projects" category in the navigator. It is not 100% reproducible, but it happens very often in our product. I managed to catch it in the debugger, and it seem that as part of removing the tree item representing the project, setSelectionToWidget is called, which eventually results in a new tree item being created for the deleted project, which the loop in CommonWorkingSetViewer.remove(Object[]) then tries to delete again. Here is the stack trace from the debugge: Thread [main] (Evaluating) CommonWorkingSetViewer(StructuredViewer).associate(Object, Item) line: 560 CommonWorkingSetViewer(AbstractTreeViewer).associate(Object, Item) line: 444 CommonWorkingSetViewer(AbstractTreeViewer).doUpdateItem(Widget, Object, boolean) line: 614 StructuredViewer$UpdateItemSafeRunnable.run() line: 434 InternalPlatform.run(ISafeRunnable) line: 1044 Platform.run(ISafeRunnable) line: 783 JFaceUtil$1.run(ISafeRunnable) line: 44 SafeRunnable.run(ISafeRunnable) line: 148 CommonWorkingSetViewer(StructuredViewer).updateItem(Widget, Object) line: 1763 CommonWorkingSetViewer(AbstractTreeViewer).createTreeItem(Widget, Object, int) line: 535 CommonWorkingSetViewer(CommonViewer).createTreeItem(Widget, Object, int) line: 201 AbstractTreeViewer$1.run() line: 514 BusyIndicator.showWhile(Display, Runnable) line: 69 CommonWorkingSetViewer(AbstractTreeViewer).createChildren(Widget) line: 494 CommonWorkingSetViewer(AbstractTreeViewer).internalExpand(Object, boolean) line: 1076 CommonWorkingSetViewer(AbstractTreeViewer).setSelectionToWidget(List, boolean) line: 1613 CommonWorkingSetViewer(StructuredViewer).setSelectionToWidget(ISelection, boolean) line: 1494 CommonWorkingSetViewer.setSelectionToWidget(ISelection, boolean) line: 343 CommonWorkingSetViewer(StructuredViewer).preservingSelection(Runnable) line: 1208 CommonWorkingSetViewer.preservingSelection(Runnable) line: 336 CommonWorkingSetViewer(AbstractTreeViewer).remove(Object[]) line: 1420 CommonWorkingSetViewer(CommonViewer).removeWithoutRefresh(Object[]) line: 166 CommonWorkingSetViewer.remove(Object[]) line: 207 CommonWorkingSetViewer(AbstractTreeViewer).remove(Object) line: 1442 DelegateShowProjectContentProvider$3.run() line: 307 DelegateShowProjectContentProvider$5.run() line: 337 RunnableLock.run() line: 35 UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 123 Display.runAsyncMessages(boolean) line: 3102 Display.readAndDispatch() line: 2761 Workbench.runEventLoop(Window$IExceptionHandler, Display) line: 1699 Workbench.runUI() line: 1663 Workbench.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 367
Created attachment 39527 [details] Thread dump for the problem
Created attachment 39778 [details] proposed patch
Attached proposed patch, which has been tested and verified by the originator. The problem was we were trying to preserve a selection to a widget which was being removed. So, we detect that the selection is being deleted and do not try to preserve the selection in this case.
+1 for WTP 1.0.3 - seems like a very serious bug and worth fixing.
+1
+1 (I'm not sure its needed, but the patch does't seem to gaurd for threading issues? So, I'm just asking to re-think in light of threads. If you believe there are none, seems your patch fixes the problem it was intended to. Thanks).
Patch released for the first WTP 1.0.3 build. David, I did not view it worthwhile to add any threading specific code as this is a dead base and will be replaced in 1.5 by the eclipse common navigator. It seemed easiest to fix problem at hand then to risk regressions.
The org.eclipse.jst.common.navigator.java and org.eclipse.jst.web_core.feature plugin version id's have been incremented accordingly.
verified 20060925
Closing as verified.
