Bugzilla – Full Text Bug Listing
| Summary: | stack overflow error from working set management | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Eugene Kuleshov <ekuleshov> | ||||||||||
| Component: | UI | Assignee: | Eric Moffatt <emoffatt> | ||||||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||||||
| Severity: | major | ||||||||||||
| Priority: | P3 | CC: | bokowski, eclipse, hsoliwal, mik.kersten, Mike_Wilson, nboldt, ob1.eclipse, philippe_mulet, steffen.pingel, wmitsuda | ||||||||||
| Version: | 3.3 | ||||||||||||
| Target Milestone: | 3.5 | ||||||||||||
| Hardware: | PC | ||||||||||||
| OS: | Windows XP | ||||||||||||
| Whiteboard: | |||||||||||||
| Bug Depends on: | 274631 | ||||||||||||
| Bug Blocks: | |||||||||||||
| Attachments: |
|
||||||||||||
|
Description
Eugene Kuleshov
Leo saw this once last week but we could not reproduce it. Did it cause any bad behavior? (In reply to comment #1) > Leo saw this once last week but we could not reproduce it. Did it cause any > bad behavior? Nothing obvious. Strange that it touched working sets at all... Here were my findings. Pattern seems to be the following: 1) Upon starting up, workspace locks up with a 'creating file buffer' message in the status bar. 2) Kill the workbench and attempt to start up again. Starting up fails during the Eclipse splash screen. Get the error dump seen above. 3) Start up again. See 'Mylar Monitor stop failed' entry in the Error log with the following stack trace: java.lang.NullPointerException at org.eclipse.mylyn.monitor.ui.MonitorUiPlugin.stop(MonitorUiPlugin.java:143) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$3.run(BundleContextImpl.java:1040) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.stop(BundleContextImpl.java:1036) at org.eclipse.osgi.framework.internal.core.BundleHost.stopWorker(BundleHost.java:457) at org.eclipse.osgi.framework.internal.core.AbstractBundle.suspend(AbstractBundle.java:526) at org.eclipse.osgi.framework.internal.core.Framework.suspendBundle(Framework.java:1148) at org.eclipse.osgi.framework.internal.core.StartLevelManager.decFWSL(StartLevelManager.java:675) at org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:291) at org.eclipse.osgi.framework.internal.core.StartLevelManager.shutdown(StartLevelManager.java:261) at org.eclipse.osgi.framework.internal.core.SystemBundle.suspend(SystemBundle.java:188) at org.eclipse.osgi.framework.internal.core.Framework.shutdown(Framework.java:622) at org.eclipse.osgi.framework.internal.core.Framework.close(Framework.java:525) at org.eclipse.osgi.framework.internal.core.OSGi.close(OSGi.java:41) at org.eclipse.core.runtime.adaptor.EclipseStarter.shutdown(EclipseStarter.java:399) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:197) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:589) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:504) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:443) at org.eclipse.equinox.launcher.Main.run(Main.java:1169) at org.eclipse.equinox.launcher.Main.main(Main.java:1144) I cannot reproduce consistently. I would guess the MonitorUiPlugin.stop() exception results from the failure to startup in step 2. The working sets exception I would guess is the result of the lock up in step 1 (bad/incomplete cleanup of working sets?). The question is what is causing the 'creating file buffer' lockup? I sometimes see that message when switching tasks, but no lock ups then. I hit this as well after I had killed my workspace. -- Error Log -- Date: Wed Jul 04 16:55:31 PDT 2007 Message: task activity listener failed: org.eclipse.mylyn.internal.tasks.ui.workingsets.TaskWorkingSetUpdater@f90b1a Severity: Error Plugin ID: org.eclipse.mylyn Stack Trace: java.lang.StackOverflowError at java.util.zip.ZipFile.getEntry(Unknown Source) at java.util.jar.JarFile.getEntry(Unknown Source) at java.util.jar.JarFile.getJarEntry(Unknown Source) at sun.misc.URLClassPath$JarLoader.getResource(Unknown Source) at sun.misc.URLClassPath$JarLoader.findResource(Unknown Source) at sun.misc.URLClassPath.findResource(Unknown Source) at java.net.URLClassLoader$2.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findResource(Unknown Source) at java.lang.ClassLoader.getResource(Unknown Source) at java.lang.ClassLoader.getResource(Unknown Source) at java.lang.ClassLoader.getResource(Unknown Source) at org.eclipse.core.runtime.internal.adaptor.ContextFinder.getResource(ContextFinder.java:142) at java.lang.ClassLoader.getResourceAsStream(Unknown Source) at javax.xml.parsers.SecuritySupport$4.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at javax.xml.parsers.SecuritySupport.getResourceAsStream(Unknown Source) at javax.xml.parsers.FactoryFinder.findJarServiceProvider(Unknown Source) at javax.xml.parsers.FactoryFinder.find(Unknown Source) at javax.xml.parsers.DocumentBuilderFactory.newInstance(Unknown Source) at org.eclipse.ui.XMLMemento.createWriteRoot(XMLMemento.java:133) at org.eclipse.ui.internal.AbstractWorkingSetManager.saveState(AbstractWorkingSetManager.java:721) at org.eclipse.ui.internal.WorkingSetManager.saveState(WorkingSetManager.java:138) at org.eclipse.ui.internal.WorkingSetManager.workingSetChanged(WorkingSetManager.java:160) at org.eclipse.ui.internal.AbstractWorkingSet.fireWorkingSetChanged(AbstractWorkingSet.java:119) at org.eclipse.ui.internal.AggregateWorkingSet.constructElements(AggregateWorkingSet.java:88) at org.eclipse.ui.internal.AggregateWorkingSet.propertyChange(AggregateWorkingSet.java:186) at org.eclipse.ui.internal.AbstractWorkingSetManager$4.run(AbstractWorkingSetManager.java:364) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.ui.internal.AbstractWorkingSetManager$3.run(AbstractWorkingSetManager.java:371) at org.eclipse.ui.internal.AbstractWorkingSetManager.firePropertyChange(AbstractWorkingSetManager.java:377) at org.eclipse.ui.internal.AbstractWorkingSetManager.workingSetChanged(AbstractWorkingSetManager.java:400) 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.AggregateWorkingSet.constructElements(AggregateWorkingSet.java:88) at org.eclipse.ui.internal.AggregateWorkingSet.propertyChange(AggregateWorkingSet.java:186) at org.eclipse.ui.internal.AbstractWorkingSetManager$4.run(AbstractWorkingSetManager.java:364) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.ui.internal.AbstractWorkingSetManager$3.run(AbstractWorkingSetManager.java:371) at org.eclipse.ui.internal.AbstractWorkingSetManager.firePropertyChange(AbstractWorkingSetManager.java:377) at org.eclipse.ui.internal.AbstractWorkingSetManager.workingSetChanged(AbstractWorkingSetManager.java:400) 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.AggregateWorkingSet.constructElements(AggregateWorkingSet.java:88) at org.eclipse.ui.internal.AggregateWorkingSet.propertyChange(AggregateWorkingSet.java:186) at org.eclipse.ui.internal.AbstractWorkingSetManager$4.run(AbstractWorkingSetManager.java:364) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.ui.internal.AbstractWorkingSetManager$3.run(AbstractWorkingSetManager.java:371) at org.eclipse.ui.internal.AbstractWorkingSetManager.firePropertyChange(AbstractWorkingSetManager.java:377) at org.eclipse.ui.internal.AbstractWorkingSetManager.workingSetChanged(AbstractWorkingSetManager.java:400) 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.AggregateWorkingSet.constructElements(AggregateWorkingSet.java:88) at org.eclipse.ui.internal.AggregateWorkingSet.propertyChange(AggregateWorkingSet.java:186) at org.eclipse.ui.internal.AbstractWorkingSetManager$4.run(AbstractWorkingSetManager.java:364) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.ui.internal.AbstractWorkingSetManager$3.run(AbstractWorkingSetManager.java:371) at org.eclipse.ui.internal.AbstractWorkingSetManager.firePropertyChange(AbstractWorkingSetManager.java:377) at org.eclipse.ui.internal.AbstractWorkingSetManager.workingSetChanged(AbstractWorkingSetManager.java:400) 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.AggregateWorkingSet.constructElements(AggregateWorkingSet.java:88) at org.eclipse.ui.internal.AggregateWorkingSet.propertyChange(AggregateWorkingSet.java:186) at org.eclipse.ui.internal.AbstractWorkingSetManager$4.run(AbstractWorkingSetManager.java:364) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.ui.internal.AbstractWorkingSetManager$3.run(AbstractWorkingSetManager.java:371) at org.eclipse.ui.internal.AbstractWorkingSetManager.firePropertyChange(AbstractWorkingSetManager.java:377) at org.eclipse.ui.internal.AbstractWorkingSetManager.workingSetChanged(AbstractWorkingSetManager.java:400) 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.AggregateWorkingSet.constructElements(AggregateWorkingSet.java:88) at org.eclipse.ui.internal.AggregateWorkingSet.propertyChange(AggregateWorkingSet.java:186) at org.eclipse.ui.internal.AbstractWorkingSetManager$4.run(AbstractWorkingSetManager.java:364) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.ui.internal.AbstractWorkingSetManager$3.run(AbstractWorkingSetManager.java:371) at org.eclipse.ui.internal.AbstractWorkingSetManager.firePropertyChange(AbstractWorkingSetManager.java:377) at org.eclipse.ui.internal.AbstractWorkingSetManager.workingSetChanged(AbstractWorkingSetManager.java:400) 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.AggregateWorkingSet.constructElements(AggregateWorkingSet.java:88) at org.eclipse.ui.internal.AggregateWorkingSet.propertyChange(AggregateWorkingSet.java:186) at org.eclipse.ui.internal.AbstractWorkingSetManager$4.run(AbstractWorkingSetManager.java:364) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.ui.internal.AbstractWorkingSetManager$3.run(AbstractWorkingSetManager.java:371) at org.eclipse.ui.internal.AbstractWorkingSetManager.firePropertyChange(AbstractWorkingSetManager.java:377) at org.eclipse.ui.internal.AbstractWorkingSetManager.workingSetChanged(AbstractWorkingSetManager.java:400) 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.AggregateWorkingSet.constructElements(AggregateWorkingSet.java:88) at org.eclipse.ui.internal.AggregateWorkingSet.propertyChange(AggregateWorkingSet.java:186) at org.eclipse.ui.internal.AbstractWorkingSetManager$4.run(AbstractWorkingSetManager.java:364) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.ui.internal.AbstractWorkingSetManager$3.run(AbstractWorkingSetManager.java:371) at org.eclipse.ui.internal.AbstractWorkingSetManager.firePropertyChange(AbstractWorkingSetManager.java:377) at org.eclipse.ui.internal.AbstractWorkingSetManager.workingSetChanged(AbstractWorkingSetManager.java:400) 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.AggregateWorkingSet.constructElements(AggregateWorkingSet.java:88) at org.eclipse.ui.internal.AggregateWorkingSet.propertyChange(AggregateWorkingSet.java:186) at org.eclipse.ui.internal.AbstractWorkingSetManager$4.run(AbstractWorkingSetManager.java:364) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.ui.internal.AbstractWorkingSetManager$3.run(AbstractWorkingSetManager.java:371) at org.eclipse.ui.internal.AbstractWorkingSetManager.firePropertyChange(AbstractWorkingSetManager.java:377) at org.eclipse.ui.internal.AbstractWorkingSetManager.workingSetChanged(AbstractWorkingSetManager.java:400) 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.AggregateWorkingSet.constructElements(AggregateWorkingSet.java:88) at org.eclipse.ui.internal.AggregateWorkingSet.propertyChange(AggregateWorkingSet.java:186) at org.eclipse.ui.internal.AbstractWorkingSetManager$4.run(AbstractWorkingSetManager.java:364) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.ui.internal.AbstractWorkingSetManager$3.run(AbstractWorkingSetManager.java:371) at org.eclipse.ui.internal.AbstractWorkingSetManager.firePropertyChange(AbstractWorkingSetManager.java:377) at org.eclipse.ui.internal.AbstractWorkingSetManager.workingSetChanged(AbstractWorkingSetManager.java:400) 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.AggregateWorkingSet.constructElements(AggregateWorkingSet.java:88) at org.eclipse.ui.internal.AggregateWorkingSet.propertyChange(AggregateWorkingSet.java:186) at org.eclipse.ui.internal.AbstractWorkingSetManager$4.run(AbstractWorkingSetManager.java:364) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.ui.internal.AbstractWorkingSetManager$3.run(AbstractWorkingSetManager.java:371) at org.eclipse.ui.internal.AbstractWorkingSetManager.firePropertyChange(AbstractWorkingSetManager.java:377) at org.eclipse.ui.internal.AbstractWorkingSetManager.workingSetChanged(AbstractWorkingSetManager.java:400) 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.AggregateWorkingSet.constructElements(AggregateWorkingSet.java:88) at org.eclipse.ui.internal.AggregateWorkingSet.propertyChange(AggregateWorkingSet.java:186) at org.eclipse.ui.internal.AbstractWorkingSetManager$4.run(AbstractWorkingSetManager.java:364) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.ui.internal.AbstractWorkingSetManager$3.run(AbstractWorkingSetManager.java:371) at org.eclipse.ui.internal.AbstractWorkingSetManager.firePropertyChange(AbstractWorkingSetManager.java:377) at org.eclipse.ui.internal.AbstractWorkingSetManager.workingSetChanged(AbstractWorkingSetManager.java:400) 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.AggregateWorkingSet.constructElements(AggregateWorkingSet.java:88) at org.eclipse.ui.internal.AggregateWorkingSet.propertyChange(AggregateWorkingSet.java:186) at org.eclipse.ui.internal.AbstractWorkingSetManager$4.run(AbstractWorkingSetManager.java:364) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.ui.internal.AbstractWorkingSetManager$3.run(AbstractWorkingSetManager.java:371) at org.eclipse.ui.internal.AbstractWorkingSetManager.firePropertyChange(AbstractWorkingSetManager.java:377) at org.eclipse.ui.internal.AbstractWorkingSetManager.workingSetChanged(AbstractWorkingSetManager.java:400) 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.AggregateWorkingSet.constructElements(AggregateWorkingSet.java:88) at org.eclipse.ui.internal.AggregateWorkingSet.propertyChange(AggregateWorkingSet.java:186) at org.eclipse.ui.internal.AbstractWorkingSetManager$4.run(AbstractWorkingSetManager.java:364) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.ui.internal.AbstractWorkingSetManager$3.run(AbstractWorkingSetManager.java:371) at org.eclipse.ui.internal.AbstractWorkingSetManager.firePropertyChange(AbstractWorkingSetManager.java:377) at org.eclipse.ui.internal.AbstractWorkingSetManager.workingSetChanged(AbstractWorkingSetManager.java:400) 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.AggregateWorkingSet.constructElements(AggregateWorkingSet.java:88) at org.eclipse.ui.internal.AggregateWorkingSet.propertyChange(AggregateWorkingSet.java:186) at org.eclipse.ui.internal.AbstractWorkingSetManager$4.run(AbstractWorkingSetManager.java:364) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.ui.internal.AbstractWorkingSetManager$3.run(AbstractWorkingSetManager.java:371) at org.eclipse.ui.internal.AbstractWorkingSetManager.firePropertyChange(AbstractWorkingSetManager.java:377) at org.eclipse.ui.internal.AbstractWorkingSetManager.workingSetChanged(AbstractWorkingSetManager.java:400) 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.AggregateWorkingSet.constructElements(AggregateWorkingSet.java:88) at org.eclipse.ui.internal.AggregateWorkingSet.propertyChange(AggregateWorkingSet.java:186) at org.eclipse.ui.internal.AbstractWorkingSetManager$4.run(AbstractWorkingSetManager.java:364) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.ui.internal.AbstractWorkingSetManager$3.run(AbstractWorkingSetManager.java:371) at org.eclipse.ui.internal.AbstractWorkingSetManager.firePropertyChange(AbstractWorkingSetManager.java:377) at org.eclipse.ui.internal.AbstractWorkingSetManager.workingSetChanged(AbstractWorkingSetManager.java:400) 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.AggregateWorkingSet.constructElements(AggregateWorkingSet.java:88) at org.eclipse.ui.internal.AggregateWorkingSet.propertyChange(AggregateWorkingSet.java:186) at org.eclipse.ui.internal.AbstractWorkingSetManager$4.run(AbstractWorkingSetManager.java:364) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.ui.internal.AbstractWorkingSetManager$3.run(AbstractWorkingSetManager.java:371) at org.eclipse.ui.internal.AbstractWorkingSetManager.firePropertyChange(AbstractWorkingSetManager.java:377) at org.eclipse.ui.internal.AbstractWorkingSetManager.workingSetChanged(AbstractWorkingSetManager.java:400) 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.AggregateWorkingSet.constructElements(AggregateWorkingSet.java:88) at org.eclipse.ui.internal.AggregateWorkingSet.propertyChange(AggregateWorkingSet.java:186) at org.eclipse.ui.internal.AbstractWorkingSetManager$4.run(AbstractWorkingSetManager.java:364) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.ui.internal.AbstractWorkingSetManager$3.run(AbstractWorkingSetManager.java:371) at org.eclipse.ui.internal.AbstractWorkingSetManager.firePropertyChange(AbstractWorkingSetManager.java:377) at org.eclipse.ui.internal.AbstractWorkingSetManager.workingSetChanged(AbstractWorkingSetManager.java:400) 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.AggregateWorkingSet.constructElements(AggregateWorkingSet.java:88) at org.eclipse.ui.internal.AggregateWorkingSet.propertyChange(AggregateWorkingSet.java:186) at org.eclipse.ui.internal.AbstractWorkingSetManager$4.run(AbstractWorkingSetManager.java:364) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.ui.internal.AbstractWorkingSetManager$3.run(AbstractWorkingSetManager.java:371) at org.eclipse.ui.internal.AbstractWorkingSetManager.firePropertyChange(AbstractWorkingSetManager.java:377) at org.eclipse.ui.internal.AbstractWorkingSetManager.workingSetChanged(AbstractWorkingSetManager.java:400) 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.AggregateWorkingSet.constructElements(AggregateWorkingSet.java:88) at org.eclipse.ui.internal.AggregateWorkingSet.propertyChange(AggregateWorkingSet.java:186) at org.eclipse.ui.internal.AbstractWorkingSetManager$4.run(AbstractWorkingSetManager.java:364) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.ui.internal.AbstractWorkingSetManager$3.run(AbstractWorkingSetManager.java:371) at org.eclipse.ui.internal.AbstractWorkingSetManager.firePropertyChange(AbstractWorkingSetManager.java:377) at org.eclipse.ui.internal.AbstractWorkingSetManager.workingSetChanged(AbstractWorkingSetManager.java:400) 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.AggregateWorkingSet.constructElements(AggregateWorkingSet.java:88) at org.eclipse.ui.internal.AggregateWorkingSet.propertyChange(AggregateWorkingSet.java:186) at org.eclipse.ui.internal.AbstractWorkingSetManager$4.run(AbstractWorkingSetManager.java:364) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) From bug 195325: Severity: Error Plugin ID: org.eclipse.mylyn Stack Trace: java.lang.StackOverflowError at org.eclipse.ui.internal.AggregateWorkingSet.restoreWorkingSet(AggregateWorkingSet.java:199) at org.eclipse.ui.internal.AbstractWorkingSet.getElementsArray(AbstractWorkingSet.java:151) at org.eclipse.ui.internal.AbstractWorkingSet.getElements(AbstractWorkingSet.java:139) at org.eclipse.ui.internal.AggregateWorkingSet.constructElements(AggregateWorkingSet.java:83) at org.eclipse.ui.internal.AggregateWorkingSet.restoreWorkingSet(AggregateWorkingSet.java:212) at org.eclipse.ui.internal.AbstractWorkingSet.getElementsArray(AbstractWorkingSet.java:151) at org.eclipse.ui.internal.AbstractWorkingSet *** Bug 195325 has been marked as a duplicate of this bug. *** Try this: -- activate some working set with query -- create new task that would match that query and submit it to the repo -- after it submitted (but before it added to the query) activate task -- enjoy the stack overflow exception Any update on this? It seems like this exception is screwing up the task history and I am getting it pretty much on every task activation. I haven't had a chance to work on this yet but hope to start on it tomorrow. From what I have seen restarting the workbench twice will make this exception go away, since that seems to fix the malformed memento. *** Bug 194699 has been marked as a duplicate of this bug. *** *** Bug 194699 has been marked as a duplicate of this bug. *** If anyone sees this with 2.1M1 please post, recent fixes may have resolved it. Tod: I wonder if this should be moved over to Platform? Which person/component is responsible for working set externalization? It looks like some double activation of a working set could cause the Platfrom to not externalize working sets correctly, which could then cause the workbench to fail to start due to the stack overflow visible in the description. This would only happen if the workbench crashed, not if it exited properly (perhaps some clean-up is done with the save that happens on exit). On the Mylyn end we want to make sure that we don't trigger this, but since the failure is so severe I think that Platform should be defensive to this kind of state in the XML and simply discard the failed working set. Removing it from from workingsets.xml manually always did the trick. Feel free to open a new bug or punt this one to me. I'll take a look at it for 3.4. Eugene, Mik, have either of you guys had reports of this occurring recently? (In reply to comment #14) > Eugene, Mik, have either of you guys had reports of this occurring recently? I am not using 3.4 builds just yet, but I've seen this issue triggered not only by Mylyn's UI, though detail are escaping me. I have not seen this recurring in 3.4M1, although I made some fixes in Mylyn UI to avoid this happening around the same time as I updated. It would only happen to me if the workbench was killed, and I have killed my workbench multiple times since. So no real data from me. Eugene: are you saying that you have seen this occur on a recent (past 3 weeks) Mylyn dev build when using Eclipse 3.3.0? (In reply to comment #16) > Eugene: are you saying that you have seen this occur on a recent (past 3 weeks) > Mylyn dev build when using Eclipse 3.3.0? I almost sure it was last week. I will let you know if it will happen again. Just got it again after restarting Eclipse from update manager (i.e. uninstall some plugins from Manage Configuration, restart, install some plugin, restart). FWIW, I ma sill getting this error on both Eclipse 3.3 and last 3.4m3. org.eclipse.swt.SWTException: Failed to execute runnable (java.lang.StackOverflowError) at org.eclipse.swt.SWT.error(SWT.java:3706) at org.eclipse.swt.SWT.error(SWT.java:3624) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:133) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3721) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3358) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2395) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2359) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2225) at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:468) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:288) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:463) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:106) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:193) 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:362) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:175) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:515) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:455) at org.eclipse.equinox.launcher.Main.run(Main.java:1193) at org.eclipse.equinox.launcher.Main.main(Main.java:1169) Caused by: java.lang.StackOverflowError at org.eclipse.ui.XMLMemento.getChildren(XMLMemento.java:223) at org.eclipse.ui.internal.AggregateWorkingSet.restoreWorkingSet(AggregateWorkingSet.java:199) at org.eclipse.ui.internal.AbstractWorkingSet.getElementsArray(AbstractWorkingSet.java:151) at org.eclipse.ui.internal.AbstractWorkingSet.getElements(AbstractWorkingSet.java:139) at org.eclipse.ui.internal.AggregateWorkingSet.constructElements(AggregateWorkingSet.java:83) at org.eclipse.ui.internal.AggregateWorkingSet.restoreWorkingSet(AggregateWorkingSet.java:212) at org.eclipse.ui.internal.AbstractWorkingSet.getElementsArray(AbstractWorkingSet.java:151) at org.eclipse.ui.internal.AbstractWorkingSet.getElements(AbstractWorkingSet.java:139) at org.eclipse.ui.internal.AggregateWorkingSet.constructElements(AggregateWorkingSet.java:83) at org.eclipse.ui.internal.AggregateWorkingSet.restoreWorkingSet(AggregateWorkingSet.java:212) at org.eclipse.ui.internal.AbstractWorkingSet.getElementsArray(AbstractWorkingSet.java:151) at org.eclipse.ui.internal.AbstractWorkingSet.getElements(AbstractWorkingSet.java:139) (last 4 lines repeated many many times) I will try to get to the bottom of this in M4. (In reply to comment #20) > I will try to get to the bottom of this in M4. Thanks Kim Kim: did you fix something related to this? I haven't seen it again and haven't seen it reported since comment#16. Mik: no, I haven't. I dug a bit but didn't get anywhere with it. Have you guys changed your working set code at all? Perhaps changed how/when you're hooking listeners? Yes, we have changed that code considerably since the failure was reported, so unfortunately it's hard for me to say what fixed it on our end. I haven't seen errors in the log for some time, but there is one weird issue that is quite annoying. I have 2 java working sets created using "Configure Working Sets" in the Package Explorer view. Those have 20..30 projects each and they disappear every time I install something using Update Manager. I think I recreated those working sets 20 times already, but there is no errors in the logs. Steffen: I think that you have seen a similar problem, also without anything in the Error Log? My guess is that what's happening is that the workbench is being improperly closed by the Update Manager (bug 107280) and that the working set support is listening to shellClosed() or something to that effect before saving it's working sets, and either fails to save them or only saves them partially. Kim: if that's the case, I think it would be worth exploring a more pro-active save? Working sets are a pretty significant time investment for users to set up, so it's painful when they're lost. Yes, my working sets file was corrupted after the update manager had restarted the workbench. I was able to manually repair it though (bug 220473). I lost part of my task list during the same update as well so the restart must have happened at a bad point in time. Will attempt another kick at this can in RC1. Thanks Kim! For what it worth, I haven't seen the stack overflows lately, but it is been loosing my Java working sets configuration until I deleted all Mylyn working sets. I don't know it that is related. (In reply to comment #30) > For what it worth, I haven't seen the stack overflows lately, but it is been > loosing my Java working sets configuration until I deleted all Mylyn working > sets. I don't know it that is related. > I haven't been able to reproduce this issue but we have fixed a bug in RC1 (bug 94825) that pertains to the shutdown lifecycle of the working set manager. Although I can't confirm that is indeed the cause of this problem it MAY indeed be possible. Fingers are crossed, at least. I'm not done digging just yet - I want to try the update scenario. Mylyn guys: Do you have code that manipulates the window working set by chance? (In reply to comment #32) > Mylyn guys: Do you have code that manipulates the window working set by chance? that would be yes (In reply to comment #33) > (In reply to comment #32) > > Mylyn guys: Do you have code that manipulates the window working set by chance? > > that would be yes > Do you have code that could potentially add a window working set to itself? :) (In reply to comment #34) > > that would be yes > Do you have code that could potentially add a window working set to itself? :) That I am not sure. I did wrote initial working set implementation, but Mik changed it quite a bit and added mixed resources support into the task working set afterwards. (In reply to comment #35) > (In reply to comment #34) > > > that would be yes > > Do you have code that could potentially add a window working set to itself? :) > > That I am not sure. I did wrote initial working set implementation, but Mik > changed it quite a bit and added mixed resources support into the task working > set afterwards. > We dont protect against this possibility in the workbench although we should. My concern is that it may be a violation of API if we start aggregate working sets from inclusion in the component list of aggregate sets. Perhaps it's sufficient to guard against the case where the set is trying to add itself. At any rate, it'd be helpful to know if it's possible that you could be doing this at your end. Could you point me at some code at your end that deals with working sets? The code is in the org.eclipse.mylyn.tasks.ui plug-in. Most of the implementation is in the org.eclipse.mylyn.internal.tasks.ui.workingsets package (you can search for type names starting with TaskWorkingSet...). A team project set is available here: http://www.eclipse.org/mylyn/doc/dev/mylyn.psf (In reply to comment #36) > Could you point me at some code at your end that deals with working sets? Here are few classes that probably relevant to this: /org.eclipse.mylyn.tasks.ui/src/org/eclipse/mylyn/internal/tasks/ui/actions/TaskWorkingSetAction.java /org.eclipse.mylyn.tasks.ui/src/org/eclipse/mylyn/internal/tasks/ui/workingsets/TaskWorkingSetUpdater.java /org.eclipse.mylyn.tasks.ui/src/org/eclipse/mylyn/internal/tasks/ui/dialogs/AbstractWorkingSetDialogCOPY.java This is marked as P1, and for 3.4 RC1. That should imply it's been fixed by now. What is the status? (In reply to comment #39) > This is marked as P1, and for 3.4 RC1. That should imply it's been fixed by > now. What is the status? > There is no fix as of yet but I have a pretty good idea of why it's happening and a candidate fix in mind. I would like to move this to RC2. Kim: let me know if we can help in any way, or if you want any specific code samples from Mylyn attached to this bug. I don't think I've seen this since 3.4M1 (comment#12), but any additional safety with working set saving seems like a good idea, because it's quite painful to have to recreate the working sets by hand. (In reply to comment #41) > Kim: let me know if we can help in any way, or if you want any specific code > samples from Mylyn attached to this bug. I don't think I've seen this since > 3.4M1 (comment#12), but any additional safety with working set saving seems > like a good idea, because it's quite painful to have to recreate the working > sets by hand. > I've started looking through your working set code, hoping to find a place where you might be getting the window working set (via the window/page or from the manager itself) and adding it to itself. I haven't gotten very far - I've been distracted by several issues - but if you have an inking of where this could potentially be happing that'd be helpful. A check at our end for this case seems sensible but I'm hesitant to do it so late if we're not entirely sure it's to blame. The biggest issue I have with the fix I'm thinking of is that it may be an API violation - our doc doesn't say anything about filtering content from the window set automatically. Actually, I should clarify - it may not be the window set itself but another aggregate working set (if you guys use those)... TaskSelectionDialog.SelectWorkingSetAction.run() calls PlatformUI.getWorkbench().getWorkingSetManager().createWorkingSetSelectionDialog(...), which indirectly may create a aggregate working set and set it as window working set (because I'm passing multi=false). BTW Kim, are you willing to fix the bug#217906 for 3.4? Created attachment 100844 [details]
mylyn/context/zip
(In reply to comment #44) > TaskSelectionDialog.SelectWorkingSetAction.run() calls > PlatformUI.getWorkbench().getWorkingSetManager().createWorkingSetSelectionDialog(...), > which indirectly may create a aggregate working set and set it as window > working set (because I'm passing multi=false). > > BTW Kim, are you willing to fix the bug#217906 for 3.4? > Mmmm. Looking at this code path I'm not sure that it is the precipitator of this problem. We need a case where working set A contains A, or A contains B contains A, or a variation on that theme. I dont see where we could get this from this code. At this point I'm inclined to defer this to 3.5. As soon as 3.4 is out the door I put in the fix that prevents a set from containing itself (recursively) and we'll evaluate the success of that fix at that time. Does anyone object to that? (In reply to comment #46) > At this point I'm inclined to defer this to 3.5. As soon as 3.4 is out the > door I put in the fix that prevents a set from containing itself (recursively) > and we'll evaluate the success of that fix at that time. Does anyone object to > that? Kim, I am not sure about others, but I don't see the initial stack overflow symptoms anymore. However I am still losing Java working sets in the Package Explorer on every restart and only if I have at least one Mylyn working set (when no Mylyn working sets are there, it is all working ok). I don't know if it is issue in a Platform or in Mylyn, but it is definitely the most annoying one. (In reply to comment #47) > (In reply to comment #46) > > At this point I'm inclined to defer this to 3.5. As soon as 3.4 is out the > > door I put in the fix that prevents a set from containing itself (recursively) > > and we'll evaluate the success of that fix at that time. Does anyone object to > > that? > > Kim, I am not sure about others, but I don't see the initial stack overflow > symptoms anymore. However I am still losing Java working sets in the Package > Explorer on every restart and only if I have at least one Mylyn working set > (when no Mylyn working sets are there, it is all working ok). I don't know if > it is issue in a Platform or in Mylyn, but it is definitely the most annoying > one. > Is there a separate bug report for losing the JDT working sets? (In reply to comment #48) > Is there a separate bug report for losing the JDT working sets? I am not aware of any. The end result is the same as with stack overflow error, but it is hard to say if they are related. (In reply to comment #49) > (In reply to comment #48) > > Is there a separate bug report for losing the JDT working sets? > > I am not aware of any. The end result is the same as with stack overflow error, > but it is hard to say if they are related. > Well, the stack overflow has the potential of preventing the workbench from even coming up so that's a shade worse than munging your working sets (as bad as that is). Could you log a bug about the JDT problem, assigned to me? I will look at it first thing in 3.5 (or possibly 3.4.1). (In reply to comment #47) > Kim, I am not sure about others, but I don't see the initial stack overflow > symptoms anymore. However I am still losing Java working sets in the Package > Explorer on every restart and only if I have at least one Mylyn working set > (when no Mylyn working sets are there, it is all working ok). I don't know if it > is issue in a Platform or in Mylyn, but it is definitely the most annoying one. Wow, that's pretty terrible. I don't recall anyone else seeing this behavior, and I have both Java and Mylyn working sets. Please also CC me on any bugs related to this in case Mylyn could avoid triggering this behavior. Steffen: have you seen anything like this? I have seen one other report (outside of Eclipse.org) where Mylyn caused loss of working sets. Kim - pls fix the priority. If clearly a P1, then it should not be deferred until 3.5 as per definition. Created attachment 127554 [details]
JUnit that shows how it is possible to create a cycle
Here is the JUnit that creates cycle in the aggregate working sets. It turned out to be a non-trivial task :-). Here is how it could happen:
The creation of an aggregate working set is a two-step process. First, a developer calls
IWorkingSetManager#createAggregateWorkingSet()
and later:
IWorkingSetManager#addWorkingSet()
The name uniqueness if verified only in the add..() method, not in create...() method. As a result it is possible to create multiple working sets with the same name.
The last step to form a cycle happens on Eclipse restart when working sets are saved into IMemento's and different working sets with the same name become indistinguishable.
Now the question is how much we can do about it without breaking APIs. We can detect cycles (and avoid stack overflows), but it seems that either cleanup or prevention need either slight "adjustments" in API contracts or a sizable amount of extra code.
Created attachment 127694 [details]
Patch v1
This patch detects and removes cycles.
The patch adds a comment to the IWorkingSet#getElements() method saying that it can throw IllegalStateException. This is a slight change in API contract but from the practical side it makes no difference as the current behavior is to create a stack overflow. For the typical uses the exception will be caught by the aggregate working set code and logged as a proper error.
The patch contains two new JUnits to test detection and cleanup of the dependency cycles in the aggregate working sets.
Hitesh, Eric, could you have a look at the patch? Hitesh, is it possible that we can help fix this using the same 'uniqueId' (the timestamp thingie) ? I'm thinking that if the unique 'id' were used as the storage tag (rather than the label) then they'd be distinguishable at reload time. Created attachment 127804 [details] save-restore free workingset (In reply to comment #56) (In reply to comment #57) Eric, that would fix the problem partly.It sounds good, but it would require some rework in the save and restore methods, while keeping them compatible with the old way. A workingset can either be connected to a manager or not in which case I call it a 'free' workingset. A free workingset cannot be checked for clashing names and also it is not saved or restored unless done separately and explicitly . In the Junit test "testDirectCycle()" the containing workingset ,"aggregate", is a free workingset.( So is the container workingset, anyway this is saved and restored explicitly.) By running the test attached to this comment, you can notice that a free workingset is not restored. I think we should fix the saveState method, either to neglect a free working set (or to handle it).So we do not have trouble while restoring.Also, this will not change the current behaviour. We would not face this problem with a containing workingset that is connected to a manger, as the manager would not have allowed a duplicate-named workingset to begin with. For cycles , we should detect them while setting the components or creating an aggregate workingset, if detected we could log it. I realized this after posting :) . To avoid ambiguity, I meant: Containing = Contained Container = Container. In a broad sense, yes, adding Eclipse-wide unique working set IDs should prevent the scenario from the comment 54. I guess for this bug the question is if you'd like to add code to detect and handle cycles. From my experiments with the workbench, if the cycle forms at some point, the Eclipse SDK crashes on startup and the only way to get it to work is by manually editing workingsets.xml file from the org.eclipse.ui.workbench cache ("-clean" does not help). After a talk with Oleg it appears that we should do the 'belt and braces' thing; on restore we should fix existing cycles (Oleg's patch) but going forward we should switch to generating and using a unique id rather than the label in the save/restore cycle to ensure that all WS info is being restored from the correct XML info (Hitesh's work). Hitesh, can we 'upgrade' existing workspaces using the following approach? Check the fist working set we restore to see if it has a 'uniqueId' field. If not then we revert to our old code (with Oleg's cycle detection patch). If so then we're already in our new format and can read it however we want. On saves we -always- use the new field to identify a particular WS (i.e. when we write out the set of children of a WSM we'd write out the uniqueId rather than the label as we currently do). Yes Eric. We should do that. Oleg, about the patch, the constructElements() is called in a few more places than just getElements, for example in the constructor , would we have to change the JavaDoc for those API methods as well? Also, I am wondering if it makes sense to not discard a component and just ignore it in case a cycle is detected ? For example B contains A and C, and B' is added to C. Save and restore.B has lost data. What if we just logged the cycle (no exception involved) and ignore the problem component? Just thought of sharing this - although removing the problem component is certainly the better approach. Sounds good. I just checked with Oleg about the 'API' to ensure that it won't be a problem to put it in after M6 goes out...which it what I'd suggest. Is that OK with everyone? (In reply to comment #62) > What if we just logged the cycle (no exception involved) and ignore > the problem component? Then you'd get the error logged every time it is accessed - and that seems to be the situation that people generally don't like. Besides, it is not like we can log a error with a suggestion on how to fix it - there is realy no fix at that point. Oleg, I've just been kicking around your part of the cycle detection/removal code. Looks fine to me. It's a nice, localized, recursion detector. To test the tests I first applied the patch to tests only and a run of the IAggragateWorkingSetTest got me two failures. Applying the rest of the patch to the actual working set code turned the tests green. Note that the change in IWorkingSet is a (minor) API change since the code can now throw an IllegalStateException. However it's replacing a non-recoverable StackOverflow so I don't see it as an issue but it'll have to get PMC's blessing since it's past API freeze...Boris, do you see any issues with this? (In reply to comment #65) > Note that the change in IWorkingSet is a (minor) API change since the code can > now throw an IllegalStateException. However it's replacing a non-recoverable > StackOverflow so I don't see it as an issue but it'll have to get PMC's > blessing since it's past API freeze...Boris, do you see any issues with this? I see no problem with this change if it is thrown now where it used to run into a stack overflow. I don't think we need API change approval for this. Committed in >20090421. Applied Oleg's patch. I'll leave the defect open until the patch from Hitesh has been reviewed and applied... Now that bug 212583 has been committed I'll mark this as FIXED. Verified that JUnit passes and code changes are present in the I20090428-0100. |