Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Standard Widget Toolkit (SWT) » No more handles problem
No more handles problem [message #452923] Mon, 28 March 2005 20:34 Go to next message
Cameron Bateman is currently offline Cameron BatemanFriend
Messages: 39
Registered: July 2009
Member
Greetings,

I am wondering if someone can help shed some light on a NoMoreHandles
problem I am having. The exception attached to the end of this message.
The problem occurs during a repaint of a GEF GraphicalViewer FigureCanvas.
The repaint is triggered by flipping back and forth between two
EditorParts hosting these FigureCanvases. Thus, on each flip one of the
canvases is being "damaged" and repainted.

One question I have is, is it possible to run out of handles even though
the system still has plenty? I have put SWT into DEBUG mode and according
to my traces, there are only 200 handles in use by my app when the
NoMoreHandles is thrown. However, using a test program that purposely
leaks handles, more than 9000 handles can be acquired before I normally
get a NoMoreHandles exception. I know on some systems (Windows included)
spurious error messages can be generated under some strange conditions
when make low-level API calls. Could this be the case?

The problem occurs under both Eclipse/GEF 3.0 and 3.0.1. Interestingly
though, it manifests quickly on WinXP but we have not been able to
reproduce on Win2K.

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:17 23)
at org.eclipse.swt.graphics.GC.<init>(GC.java:120)
at org.eclipse.swt.graphics.GC.<init>(GC.java:87)
at
org.eclipse.draw2d.BufferedGraphicsSource.getGraphics(Buffer edGraphicsSource.java:76)
at
org.eclipse.draw2d.DeferredUpdateManager.getGraphics(Deferre dUpdateManager.java:108)
at
org.eclipse.draw2d.DeferredUpdateManager.repairDamage(Deferr edUpdateManager.java:194)
at
org.eclipse.draw2d.DeferredUpdateManager.performUpdate(Defer redUpdateManager.java:134)
at
org.eclipse.draw2d.DeferredUpdateManager.performUpdate(Defer redUpdateManager.java:118)
at org.eclipse.draw2d.LightweightSystem.paint(LightweightSystem .java:211)
at
org.eclipse.draw2d.LightweightSystem$4.handleEvent(Lightweig htSystem.java:115)
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:80 3)
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:14 67)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :2429)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:1377)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1348)
at
org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Work bench.java:254)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.j ava:141)
at
net.rim.wica.tools.studio.branding.StudioPlatform.run(Studio Platform.java:46)
at
org.eclipse.core.internal.runtime.PlatformActivator$1.run(Pl atformActivator.java:335)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:273)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.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)
Re: No more handles problem [message #453032 is a reply to message #452923] Wed, 30 March 2005 00:52 Go to previous messageGo to next message
Steve Northover is currently offline Steve NorthoverFriend
Messages: 1636
Registered: July 2009
Senior Member
Not sure why this is happening. I suggest you take it up with GEF and
provide a snippet for us to debug. If the problem is really in SWT, the bug
report will be forwarded to us.

"Cameron Bateman" <cbateman@rim.com> wrote in message
news:d35d23c1333f9949cee5aa790b73f0ca$1@www.eclipse.org...
> Greetings,
>
> I am wondering if someone can help shed some light on a NoMoreHandles
> problem I am having. The exception attached to the end of this message.
> The problem occurs during a repaint of a GEF GraphicalViewer FigureCanvas.
> The repaint is triggered by flipping back and forth between two
> EditorParts hosting these FigureCanvases. Thus, on each flip one of the
> canvases is being "damaged" and repainted.
>
> One question I have is, is it possible to run out of handles even though
> the system still has plenty? I have put SWT into DEBUG mode and according
> to my traces, there are only 200 handles in use by my app when the
> NoMoreHandles is thrown. However, using a test program that purposely
> leaks handles, more than 9000 handles can be acquired before I normally
> get a NoMoreHandles exception. I know on some systems (Windows included)
> spurious error messages can be generated under some strange conditions
> when make low-level API calls. Could this be the case?
>
> The problem occurs under both Eclipse/GEF 3.0 and 3.0.1. Interestingly
> though, it manifests quickly on WinXP but we have not been able to
> reproduce on Win2K.
>
> 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:17 23)
> at org.eclipse.swt.graphics.GC.<init>(GC.java:120)
> at org.eclipse.swt.graphics.GC.<init>(GC.java:87)
> at
>
org.eclipse.draw2d.BufferedGraphicsSource.getGraphics(Buffer edGraphicsSource
..java:76)
> at
>
org.eclipse.draw2d.DeferredUpdateManager.getGraphics(Deferre dUpdateManager.j
ava:108)
> at
>
org.eclipse.draw2d.DeferredUpdateManager.repairDamage(Deferr edUpdateManager.
java:194)
> at
>
org.eclipse.draw2d.DeferredUpdateManager.performUpdate(Defer redUpdateManager
..java:134)
> at
>
org.eclipse.draw2d.DeferredUpdateManager.performUpdate(Defer redUpdateManager
..java:118)
> at org.eclipse.draw2d.LightweightSystem.paint(LightweightSystem .java:211)
> at
>
org.eclipse.draw2d.LightweightSystem$4.handleEvent(Lightweig htSystem.java:11
5)
> 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:80 3)
> 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:14 67)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :2429)
> at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:1377)
> at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1348)
> at
>
org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Work bench.java:254)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.j ava:141)
> at
>
net.rim.wica.tools.studio.branding.StudioPlatform.run(Studio Platform.java:46
)
> at
>
org.eclipse.core.internal.runtime.PlatformActivator$1.run(Pl atformActivator.
java:335)
> at
>
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:273)
> at
>
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.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)
>
Re: No more handles problem [message #453105 is a reply to message #453032] Wed, 30 March 2005 17:26 Go to previous message
Cameron Bateman is currently offline Cameron BatemanFriend
Messages: 39
Registered: July 2009
Member
After much help from Randy and Pratik, I figured out that this was due to
a resource leak not detected by Sleak. As the Sleak home page says, it
does not detected "widget leaks", since these are rare due to "rule 2".
What I found in our code was something that was equivilent (although less
obvious) to this:

while(true)
{
GC gc = new GC(new Shell());
// do some stuff with gc
gc.dispose();
}

Even once I realized this was what was happening, I almost overlooked to
problem. Which is, of course, that a new Shell's UI resources are being
leaked on every pass. Of course, Sleak doesn't detect this, since it's a
Window handle being leaked not a graphical resource.

What's most interesting is, on W2K this didn't seem to cause any problems,
but on WinXP it eventually results in NoMoreHandles errors on *graphical*
resources (in my case Image and GC construction) even though these are not
being leaked.

I am presently improving Sleak to give a running count of default shells
(those returned by Display.getCurrent().getShells()) as well as a total
count of all Composites and Controls that exist. BTW, is there a simpler
way to do that than simply recurse the tree of children starting from
Display.getCurrent?

I hope to be able to contribute the improvements to Sleak in some form to
Eclipse.


--Cam

Steve Northover wrote:

> Not sure why this is happening. I suggest you take it up with GEF and
> provide a snippet for us to debug. If the problem is really in SWT, the bug
> report will be forwarded to us.
Previous Topic:URL for the API
Next Topic:OS Resource Management
Goto Forum:
  


Current Time: Thu Nov 14 13:39:15 GMT 2019

Powered by FUDForum. Page generated in 0.01893 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top