Bugzilla – Full Text Bug Listing
| Summary: | Eclipse crashes with empty window after start | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Thomas BAI <thomas.baier> |
| Component: | Resources | Assignee: | Platform-Resources-Inbox <platform-resources-inbox> |
| Status: | CLOSED DUPLICATE | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | Lars.Vogel, loskutov, sptaszkiewicz |
| Version: | 3.7 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Thomas BAI
Does that also happen with Eclipse Mars? I don't know how to reproduce, I've just got similar report for 3.8.2, and the code in 4.6 seem to be very similar. The problem is that SaveManager.startup doesn't catch ObjectNotFoundException which might come from the AbstractDataTree.handleNotFound on startup if the Eclipse was not properly shut down before and some internal data got corrupted. The only solution for user right now is to wipe the entire workspace and start everything from scratch. A better solution would be to make some internal cleanup tasks and wipe the appropriated corrupted data structures without crashing the IDE on startup. Stack from 3.8 (line numbers don't match 4.6, but related code is almost same). org.eclipse.core.internal.dtree.ObjectNotFoundException: Tree element '/x/y/z.class' not found. at org.eclipse.core.internal.dtree.AbstractDataTree.handleNotFound(AbstractDataTree.java:257) at org.eclipse.core.internal.dtree.DeltaDataTree.getData(DeltaDataTree.java:585) at org.eclipse.core.internal.dtree.DataDeltaNode.asBackwardDelta(DataDeltaNode.java:50) at org.eclipse.core.internal.dtree.DataDeltaNode.asBackwardDelta(DataDeltaNode.java:47) at org.eclipse.core.internal.dtree.DataDeltaNode.asBackwardDelta(DataDeltaNode.java:47) at org.eclipse.core.internal.dtree.DataDeltaNode.asBackwardDelta(DataDeltaNode.java:47) at org.eclipse.core.internal.dtree.DataDeltaNode.asBackwardDelta(DataDeltaNode.java:47) at org.eclipse.core.internal.dtree.DataDeltaNode.asBackwardDelta(DataDeltaNode.java:47) at org.eclipse.core.internal.dtree.NoDataDeltaNode.asBackwardDelta(NoDataDeltaNode.java:59) at org.eclipse.core.internal.dtree.NoDataDeltaNode.asBackwardDelta(NoDataDeltaNode.java:59) at org.eclipse.core.internal.dtree.DataDeltaNode.asBackwardDelta(DataDeltaNode.java:47) at org.eclipse.core.internal.dtree.DeltaDataTree.asBackwardDelta(DeltaDataTree.java:88) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:816) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:815) at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:792) at org.eclipse.core.internal.watson.ElementTree.immutable(ElementTree.java:518) at org.eclipse.core.internal.resources.SaveManager.restore(SaveManager.java:710) at org.eclipse.core.internal.resources.SaveManager.startup(SaveManager.java:1528) at org.eclipse.core.internal.resources.Workspace.startup(Workspace.java:2502) at org.eclipse.core.internal.resources.Workspace.open(Workspace.java:2251) at org.eclipse.core.resources.ResourcesPlugin.start(ResourcesPlugin.java:439) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:711) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:702) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:683) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:381) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:300) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:440) at org.eclipse.osgi.internal.loader.BundleLoader.setLazyTrigger(BundleLoader.java:263) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:107) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:469) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:216) at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:395) at org.eclipse.osgi.internal.loader.SingleSourcePackage.loadClass(SingleSourcePackage.java:35) at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:461) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:421) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:412) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:125) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:353) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584) at org.eclipse.equinox.launcher.Main.run(Main.java:1438) at org.eclipse.equinox.launcher.Main.main(Main.java:1414) (In reply to Andrey Loskutov from comment #2) > I don't know how to reproduce, I've just got similar report for 3.8.2, and > the code in 4.6 seem to be very similar. Not true, the code is different especially regarding handling potential ObjectNotFoundExceptions. See bug 149121 and bug 437005 which capture 2 different causes and different solutions for ObjectNotFoundExceptions. This bug was opened against 3.7 so it can be affected by either of these bugs or by some third unknown cause. Your case may have a difference cause then this bug even if the exception you see in .log is very similar. > The only solution for user right now is to wipe the entire workspace and > start everything from scratch. Not true, the right workaround is to remove the .snap file and the workspace will/should start normally. (In reply to Szymon Ptaszkiewicz from comment #3) > (In reply to Andrey Loskutov from comment #2) > > I don't know how to reproduce, I've just got similar report for 3.8.2, and > > the code in 4.6 seem to be very similar. > > Not true, the code is different especially regarding handling potential > ObjectNotFoundExceptions. See bug 149121 and bug 437005 which capture 2 > different causes and different solutions for ObjectNotFoundExceptions. This > bug was opened against 3.7 so it can be affected by either of these bugs or > by some third unknown cause. Your case may have a difference cause then this > bug even if the exception you see in .log is very similar. I've simply went over the stack in 4.7 and I didn't saw any obvious guards for ObjectNotFoundExceptions, so my assumption was that the code is still not protected and so similar to 3.8. But thanks for the hints, I will close this bug as a dup of 149121. > > The only solution for user right now is to wipe the entire workspace and > > start everything from scratch. > > Not true, the right workaround is to remove the .snap file and the workspace > will/should start normally. Thanks, I was not aware about *.snap at all, there is no trace in the official documentation for this topic, so the end user has no clue what to do, which effectively means that the only solution is to wipe the workspace :-(. *** This bug has been marked as a duplicate of bug 149121 *** |