Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 43351

Summary: [Markers] Problem View contents empty due to silent OutOfMemory error
Product: [Eclipse Project] Platform Reporter: Michael Valenta <Michael.Valenta>
Component: UIAssignee: Tod Creasey <Tod_Creasey>
Status: RESOLVED WORKSFORME QA Contact:
Severity: normal    
Priority: P3 CC: Mike_Wilson
Version: 3.0   
Target Milestone: ---   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Attachments:
Description Flags
Contents of log file none

Description Michael Valenta CLA 2003-09-19 09:50:44 EDT 
I doing testing for the new background auto-build (I20030917 with Team and 
Core from HEAD) and the problem view became empty. The titlebar still showed 
the number of problems but the view was not drawn. I will attach the log file. 
It appears that an OutOfMemory error occurred (silently) which caused the 
continued failure of the view. Either recovery should be handled properly or 
the user should be prompted to exit the workbench (as they are in other 
OutOfMemory occurances).
Comment 1 Michael Valenta CLA 2003-09-19 09:51:28 EDT 
Created attachment 6168 [details]
Contents of log file
Comment 2 Michael Valenta CLA 2003-09-19 09:58:30 EDT 
Closing and opening the view fixed the problem but resulted in the following 
exception:

!ENTRY org.eclipse.ui 4 4 Sep 19, 2003 09:50:44.271
!MESSAGE Unhandled exception caught in event loop.
!ENTRY org.eclipse.ui 4 0 Sep 19, 2003 09:50:44.303
!MESSAGE Widget is disposed
!STACK 0
org.eclipse.swt.SWTException: Widget is disposed
	at org.eclipse.swt.SWT.error(SWT.java:2369)
	at org.eclipse.swt.SWT.error(SWT.java:2299)
	at org.eclipse.swt.widgets.Widget.error(Widget.java:388)
	at org.eclipse.swt.widgets.Widget.checkWidget(Widget.java:317)
	at org.eclipse.swt.widgets.Table.setRedraw(Table.java:1808)
	at org.eclipse.ui.views.markers.internal.TableView$5.run
(TableView.java:300)
	at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
	at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages
(Synchronizer.java:102)
	at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:2165)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:1882)
	at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2037)
	at org.eclipse.ui.internal.Workbench.run(Workbench.java:2020)
	at org.eclipse.core.internal.boot.InternalBootLoader.run
(InternalBootLoader.java:858)
	at org.eclipse.core.boot.BootLoader.run(BootLoader.java:461)
	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:324)
	at org.eclipse.core.launcher.Main.basicRun(Main.java:295)
	at org.eclipse.core.launcher.Main.run(Main.java:751)
	at org.eclipse.core.launcher.Main.main(Main.java:587)
Comment 3 Carolyn MacLeod CLA 2003-12-02 13:11:00 EST 
This bug may be a duplicate of 33972.
Comment 4 Mike Wilson CLA 2004-03-03 13:31:13 EST 
One of the things that we have to be more careful of is handling OOM exceptions. These are *not* 
recoverable, and anything which prevents them from being passed up to the workbench event loop has 
to be changed to re-throw them. It is actually better if you don't even attempt to catch them.

See also, bug 42291.
Comment 5 Tod Creasey CLA 2006-04-07 10:30:07 EDT 
Closing as this appears to be stale