Community
Participate
Working Groups
(Not sure what the appropriate Component should be for this bug, so taking a guess; apologies if it's the wrong one.) Problem occurs when trying to open a large .suo - this is a binary-format Visual Studio solution-level prefs file - into an Eclipse editor view. (No, there's no good reason to want to do this; I gather it happened by accident.) This immediately crashed Eclipse, but not before the view was added to the workspace, so every subsequent launch of Eclipse tried to reopen the file and crashed again. The only way I was able to recover the workspace was by manually removing the relevant <editor> element from the ".metadata\.plugins\org.eclipse.ui.workbench\workbench.xml" config file. Problem is reproducible every time with that particular file (I'll add it as an attachment as soon as I can clear this with my line manager), even after a system reboot. It's also reproducible on a Win2K machine. It did NOT occur with a different, smaller .suo file. Relevant portion of .metadata\.log : !SESSION Jul 19, 2004 13:35:35.910 --------------------------------------------- eclipse.buildId=I200406251208 java.version=1.4.1_02 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_GB !ENTRY org.eclipse.ui 4 4 Jul 19, 2004 13:35:35.910 !MESSAGE Unhandled event loop exception !ENTRY org.eclipse.ui 4 0 Jul 19, 2004 13:35:35.925 !MESSAGE No more handles !STACK 0 org.eclipse.swt.SWTError: No more handles at org.eclipse.swt.SWT.error(SWT.java:2717) at org.eclipse.swt.SWT.error(SWT.java:2616) at org.eclipse.swt.SWT.error(SWT.java:2587) at org.eclipse.swt.graphics.Image.internal_new_GC(Image.java:1723) at org.eclipse.swt.graphics.GC.<init>(GC.java:120) at org.eclipse.swt.graphics.GC.<init>(GC.java:87) at org.eclipse.jface.text.source.AnnotationRulerColumn.doubleBufferPaint(AnnotationRulerColumn.java:528) at org.eclipse.jface.text.source.AnnotationRulerColumn.access$3(AnnotationRulerColumn.java:511) at org.eclipse.jface.text.source.AnnotationRulerColumn$1.paintControl(AnnotationRulerColumn.java:306) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:82) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:82) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:796) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:820) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:805) at org.eclipse.swt.widgets.Composite.WM_PAINT(Composite.java:803) at org.eclipse.swt.widgets.Control.windowProc(Control.java:3020) at org.eclipse.swt.widgets.Display.windowProc(Display.java:3338) at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method) at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:1467) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2429) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1377) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1348) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:254) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:141) at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:96) at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:335) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:273) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:129) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.core.launcher.Main.basicRun(Main.java:183) at org.eclipse.core.launcher.Main.run(Main.java:644) at org.eclipse.core.launcher.Main.main(Main.java:628)
Created attachment 13411 [details] File causing the crash
Have just seen this again with another, smaller .suo file (67k compared to the original attachment's 385k). It wasn't a one-off. Symptoms, .log contents, behaviour and workaround as before.
I can reproduce this problem in eclipse 3.0, but this works fine for me if I substitute the SWT from HEAD (ie.- the current 3.1 stream). So this has been fixed; changing report status accordingly.
Great, thanks. Do you want a copy of the smaller crasher-file for a regression test, or is such a test not going to be practicable? There's still the wider issue of whether the workspace should be trying to automatically reload a file on startup that caused it to crash last time. This is what made me unsure about the Component when originally filing this bug. The inescapable crash loop was nasty, but I suppose it's a question of whether this sort of thing happens often enough to justify the effort.
It's worth giving the smaller .suo a try also. If you aren't keeping up with 3.1-stream milestone releases on your end then attach the .suo here and I'll try it. Auto-opening a file that caused a previous crash was quite bad in this case. I'd suggest opening a new bug report with Platform - UI that mentions this issue specifically, and provide a link to this report as an example.
Opened Bug 72463 for the auto-open issue, as suggested. Thanks again!
Might be related to bug 68478. Isn't this a 3.0.1 candidate?
I've tracked the change that fixes this case to be bug 63571. That fix is currently not planned for inclusion in 3.0.1 because of its complexity, but if it proves to fix various scenarios then it may receive more consideration. Marking this report as a duplicate.
*** This bug has been marked as a duplicate of 63571 ***
*** Bug 75077 has been marked as a duplicate of this bug. ***
*** Bug 87436 has been marked as a duplicate of this bug. ***
