Community
Participate
Working Groups
This is a separate bug to track possible changes to the ResourceHandler or how the workbench state is persisted. For reference please see bug 404873 comment 7. Summary: If an exception is thrown while updating the selection of a PageBookView, the workbench part becomes corrupted. If the corrupted application element is persisted as part of the workbench.e4xmi, all successive attempts to load the workbench.e4xmi fail. We should look into possibly having some kind of validation before the workbench.e4xmi is loaded to circumvent these kinds of issues. -or- Have a validation process before the corrupted element is persisted in the first place. We can then alert the user that corruption exists, and give them an opportunity to recover or just delete the corrupted element. JD
Hi JD, Could you include the stack trace from the ResourceHandler? Also, could you attach the corrupt workbench.xmi file? PW
Created attachment 232241 [details] workbench.xmi - Fails to load This version of the workbench.xmi just fails to load, causing the workbench to enter into a default start-up state.
Created attachment 232242 [details] workbench.xmi - Crashes workbench This version of the workbench.xmi fails to load *and* causes the workbench to crash.
Created attachment 232243 [details] workbench.xmi - Crashes workbench (2) Here's another version that crashes the workbench
Paul, when you get a chance can you have a look at how our loading is failing with the attachments? PW
Will do, but it will have to wait until after tomorrow. Then I will be able to spend a little more time with this. I do know that when the workbench crashes, it is the result of several SWT exceptions. All resulting from the failure of: at org.eclipse.swt.widgets.Widget.checkParent(Widget.java:277) It does not seem that all of the corrupted elements in the workbench.xmi are related to CVS. So I really want to track down a replicable failure. JD
Paul: Tried to reproduce unsuccessfully in both 4.3 and 4.2.2 with the attached workbench.xmi. I think we are successfully loading workbench.xmi, but then we are failing during rendering. JD: those stack traces would be really useful.
(In reply to comment #7) > Paul: > > Tried to reproduce unsuccessfully in both 4.3 and 4.2.2 with the attached > workbench.xmi. I think we are successfully loading workbench.xmi, but then > we are failing during rendering. Same here, but I only tried using the SDK. Maybe it's necessary to have the same package/install.
Dani: > Same here, but I only tried using the SDK. Maybe it's necessary to have the > same package/install. With 4.2.2, I tried figuring that out. I added the full WST suite, plus Mylyn task interfaces (so that all the error parts were resolved). I then faked up all the resources referenced by parts in the workbench.xmi. Still, everything works. The error log still shows some action sets missing, so I haven't quite got it all, yet. JD: Can you indicate what Eclipse package you are using, and whether you are adding additional features.
I am attaching my full log and workbench configuration. I think the issue is related to loading the two resources AircraftPartsServices.xsd & .wsdl, because when I tried it in a completely new workspace the workbench loaded without issue. I will get back to this, this afternoon. We have our load meeting at 10:00 CST. JD
Created attachment 232284 [details] Workbench log of the crash
Created attachment 232285 [details] Workbench Configuration
JD, thanks for the extra material. The workbench log contains a number a StackOverflowError; I've attached the recursive loop portion of the stack trace below. The code traverses multipage editor (the wsdl or xsd editor), the CVS history view, some selectionChanged handlers, an IEclipseContext change and firing of a RunAndTrack, to name a few. JD: I assume your wsdl and xsd files are hosted in CVS. Is the history view set to "Link with Editor and Selection" by any chance? Here's the looping part of the stack trace. at org.eclipse.ui.part.PageBookView.createPage(PageBookView.java:411) at org.eclipse.ui.part.PageBookView.partActivated(PageBookView.java:763) at org.eclipse.team.internal.ui.history.GenericHistoryView.showHistoryPageFor(GenericHistoryView.java:559) at org.eclipse.team.internal.ui.history.GenericHistoryView.showHistory(GenericHistoryView.java:818) at org.eclipse.team.internal.ui.history.GenericHistoryView.access$3(GenericHistoryView.java:814) at org.eclipse.team.internal.ui.history.GenericHistoryView$2.selectionChanged(GenericHistoryView.java:364) at org.eclipse.ui.internal.e4.compatibility.SelectionService.notifyPostSelectionListeners(SelectionService.java:173) at org.eclipse.ui.internal.e4.compatibility.SelectionService.access$4(SelectionService.java:170) at org.eclipse.ui.internal.e4.compatibility.SelectionService$2.selectionChanged(SelectionService.java:86) at org.eclipse.e4.ui.internal.workbench.SelectionAggregator$4.run(SelectionAggregator.java:156) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.e4.ui.internal.workbench.SelectionAggregator.notifyPostListeners(SelectionAggregator.java:154) at org.eclipse.e4.ui.internal.workbench.SelectionAggregator.access$8(SelectionAggregator.java:151) at org.eclipse.e4.ui.internal.workbench.SelectionAggregator$8$1.run(SelectionAggregator.java:253) at org.eclipse.e4.core.contexts.RunAndTrack.runExternalCode(RunAndTrack.java:53) at org.eclipse.e4.ui.internal.workbench.SelectionAggregator$8.changed(SelectionAggregator.java:251) at org.eclipse.e4.core.internal.contexts.TrackableComputationExt.update(TrackableComputationExt.java:110) at org.eclipse.e4.core.internal.contexts.EclipseContext.processScheduled(EclipseContext.java:328) at org.eclipse.e4.core.internal.contexts.EclipseContext.set(EclipseContext.java:342) at org.eclipse.e4.ui.internal.workbench.SelectionServiceImpl.setPostSelection(SelectionServiceImpl.java:34) at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart$3.selectionChanged(CompatibilityPart.java:126) at org.eclipse.ui.part.MultiPageSelectionProvider$1.run(MultiPageSelectionProvider.java:110) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.ui.part.MultiPageSelectionProvider.fireEventChange(MultiPageSelectionProvider.java:108) at org.eclipse.ui.part.MultiPageSelectionProvider.firePostSelectionChanged(MultiPageSelectionProvider.java:102) at org.eclipse.ui.part.MultiPageEditorPart.pageChange(MultiPageEditorPart.java:869) at org.eclipse.wst.wsdl.ui.internal.asd.ASDMultiPageEditor.pageChange(ASDMultiPageEditor.java:325) at org.eclipse.ui.part.MultiPageEditorPart.setActivePage(MultiPageEditorPart.java:1083) at org.eclipse.ui.part.MultiPageEditorPart.setActiveEditor(MultiPageEditorPart.java:1219) at org.eclipse.team.ui.history.RevisionAnnotationController.findTextEditorPart(RevisionAnnotationController.java:223) at org.eclipse.team.ui.history.RevisionAnnotationController.findTextEditor(RevisionAnnotationController.java:206) at org.eclipse.team.ui.history.RevisionAnnotationController.findOpenTextEditorForFile(RevisionAnnotationController.java:200) at org.eclipse.team.ui.history.RevisionAnnotationController.findOpenTextEditorFor(RevisionAnnotationController.java:248) at org.eclipse.team.ui.history.RevisionAnnotationController.findEditorRevisonRulerColumn(RevisionAnnotationController.java:270) at org.eclipse.team.ui.history.RevisionAnnotationController.<init>(RevisionAnnotationController.java:309) at org.eclipse.team.internal.ccvs.ui.CVSHistoryPage$CVSRevisionAnnotationController.<init>(CVSHistoryPage.java:1405) at org.eclipse.team.internal.ccvs.ui.CVSHistoryPage.linkWithEditor(CVSHistoryPage.java:2016) at org.eclipse.team.internal.ccvs.ui.CVSHistoryPage.inputSet(CVSHistoryPage.java:1985) at org.eclipse.team.ui.history.HistoryPage.setInput(HistoryPage.java:59) at org.eclipse.team.internal.ui.history.GenericHistoryView.doCreatePage(GenericHistoryView.java:698) at org.eclipse.ui.part.PageBookView.createPage(PageBookView.java:411)
All is correct.. Actually that was the original bug 404873 What I have not determined is the relationship between the SOE's and the failure of the workbench.xmi to load. It seemed as though the SOE's would even happen during the normal course of use, but I haven't been able to create a replicable scenario.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
