Home » Eclipse Projects » GEF » No more handles when using ScrollableThumbnail
|
| Re: No more handles when using ScrollableThumbnail [message #232231 is a reply to message #232058] |
Mon, 26 March 2007 19:21   |
 Del Myers
Messages: 82
Registered: July 2009 |
Member |
|
|
I think that I may have found the problem:
In the Thumbnail class, there is a method ThumnailUpdater.resetTileValues()
which sets the number of tiles for the redraw based on the size of the source
figure and the maximum buffer size (256x256 pixels). In most cases, this is
fine, but I'm ending up with absolutely massive charts. When I get massive
charts, I can get in excess of 10 000-20 000 tiles per redraw. All of the gcs
for the draw are disposed properly, but 20 000 gcs is, I suppose, just too much
for the OS to create and destroy in a short period of time.
I've come up with a solution which is to create a patched version of Thumbnail
which limits the number of tiles that can be created. Unfortunately, that makes
the memory footprint a lot larger. But, if people are looking at huge graphs,
they are going to need a lot of memory anyway.
I think that this will work.
Del Myers wrote:
> I've created a GEF editor that may contain thousands of figures, and can
> get quite large. I've also created an overview for the editor using a
> ScrollableThumbnail.
>
> Things seem to work okay as long as the zoom in the editor is 1x.
> However, if I zoom in several times with the thumbnail viewer open and
> do a lot of navigation with my viewport, my workbench crashes with an
> SWTError (stack trace below).
>
> I think that there is a problem with the way that the Thumbnail is
> disposing of images. I have a feeling that not all of them are being
> properly disposed. I'm wondering if anyone else is having this problem?
>
> Error while informing user about event loop exception:
> org.eclipse.swt.SWTError: No more handles
> at org.eclipse.swt.SWT.error(SWT.java:3400)
> at org.eclipse.swt.SWT.error(SWT.java:3297)
> at org.eclipse.swt.SWT.error(SWT.java:3268)
> at org.eclipse.swt.graphics.Image.internal_new_GC(Image.java:19 35)
> at org.eclipse.swt.graphics.GC.<init>(GC.java:132)
> at
> org.eclipse.draw2d.BufferedGraphicsSource.getGraphics(Buffer edGraphicsSource.java:106)
>
> at
> org.eclipse.draw2d.DeferredUpdateManager.getGraphics(Deferre dUpdateManager.java:135)
>
> at
> org.eclipse.draw2d.DeferredUpdateManager.repairDamage(Deferr edUpdateManager.java:272)
>
> at
> org.eclipse.draw2d.DeferredUpdateManager.performUpdate(Defer redUpdateManager.java:167)
>
> at
> org.eclipse.draw2d.DeferredUpdateManager$UpdateRequest.run(D eferredUpdateManager.java:46)
>
> at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:3 5)
> at
> org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchr onizer.java:123)
>
> at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.jav a:3325)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :2971)
> at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:1930)
> at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1894)
> at
> org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Work bench.java:422)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.j ava:149)
> at
> org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplicatio n.java:95)
> at
> org.eclipse.core.internal.runtime.PlatformActivator$1.run(Pl atformActivator.java:78)
>
> at
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .runApplication(EclipseAppLauncher.java:92)
>
> at
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .start(EclipseAppLauncher.java:68)
>
> at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:400)
>
> at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:177)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce ssorImpl.java:39)
>
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe thodAccessorImpl.java:25)
>
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.eclipse.core.launcher.Main.invokeFramework(Main.java:336 )
> at org.eclipse.core.launcher.Main.basicRun(Main.java:280)
> at org.eclipse.core.launcher.Main.run(Main.java:977)
> at org.eclipse.core.launcher.Main.main(Main.java:952)
> Dialog open exception:
> org.eclipse.swt.SWTException: Unsupported color depth
> at org.eclipse.swt.SWT.error(SWT.java:3374)
> at org.eclipse.swt.SWT.error(SWT.java:3297)
> at org.eclipse.swt.SWT.error(SWT.java:3268)
> at org.eclipse.swt.graphics.Image.getImageData(Image.java:1232)
> at org.eclipse.swt.widgets.Decorations.setImages(Decorations.ja va:917)
> at org.eclipse.swt.widgets.Decorations.setImages(Decorations.ja va:1000)
> at org.eclipse.jface.window.Window.configureShell(Window.java:3 68)
> at
> org.eclipse.jface.dialogs.MessageDialog.configureShell(Messa geDialog.java:175)
>
> at org.eclipse.jface.window.Window.createShell(Window.java:497)
> at org.eclipse.jface.window.Window.create(Window.java:425)
> at org.eclipse.jface.dialogs.Dialog.create(Dialog.java:1124)
> at
> org.eclipse.ui.internal.ide.dialogs.InternalErrorDialog.open (InternalErrorDialog.java:74)
>
> at
> org.eclipse.ui.internal.ide.dialogs.InternalErrorDialog.open Question(InternalErrorDialog.java:185)
>
> at
> org.eclipse.ui.internal.ide.IDEExceptionHandler.openQuestion Dialog(IDEExceptionHandler.java:174)
>
> at
> org.eclipse.ui.internal.ide.IDEExceptionHandler.handleExcept ion(IDEExceptionHandler.java:100)
>
> at
> org.eclipse.ui.internal.ide.IDEWorkbenchAdvisor.eventLoopExc eption(IDEWorkbenchAdvisor.java:298)
>
> at
> org.eclipse.ui.internal.ExceptionHandler.handleException(Exc eptionHandler.java:62)
>
> at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:1934)
> at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1894)
> at
> org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Work bench.java:422)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.j ava:149)
> at
> org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplicatio n.java:95)
> at
> org.eclipse.core.internal.runtime.PlatformActivator$1.run(Pl atformActivator.java:78)
>
> at
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .runApplication(EclipseAppLauncher.java:92)
>
> at
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .start(EclipseAppLauncher.java:68)
>
> at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:400)
>
> at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:177)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce ssorImpl.java:39)
>
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe thodAccessorImpl.java:25)
>
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.eclipse.core.launcher.Main.invokeFramework(Main.java:336 )
> at org.eclipse.core.launcher.Main.basicRun(Main.java:280)
> at org.eclipse.core.launcher.Main.run(Main.java:977)
> at org.eclipse.core.launcher.Main.main(Main.java:952)
|
|
|
| Re: No more handles when using ScrollableThumbnail [message #232414 is a reply to message #232231] |
Fri, 30 March 2007 01:22 |
Eclipse User |
|
|
|
Originally posted by: none.ibm.com
This code is pretty mature (meaning I can't remember how it works), but it
seems like it only creates one GC for the entire pass through the source
figure. You might have a resource leak in your figure's paint methods
somewhere.
"Del Myers" <delmyers.cs@gmail.com> wrote in message
news:eu96e8$qoo$1@utils.eclipse.org...
>I think that I may have found the problem:
>
> In the Thumbnail class, there is a method
> ThumnailUpdater.resetTileValues() which sets the number of tiles for the
> redraw based on the size of the source figure and the maximum buffer size
> (256x256 pixels). In most cases, this is fine, but I'm ending up with
> absolutely massive charts. When I get massive charts, I can get in excess
> of 10 000-20 000 tiles per redraw. All of the gcs for the draw are
> disposed properly, but 20 000 gcs is, I suppose, just too much for the OS
> to create and destroy in a short period of time.
>
> I've come up with a solution which is to create a patched version of
> Thumbnail which limits the number of tiles that can be created.
> Unfortunately, that makes the memory footprint a lot larger. But, if
> people are looking at huge graphs, they are going to need a lot of memory
> anyway.
>
> I think that this will work.
>
> Del Myers wrote:
>> I've created a GEF editor that may contain thousands of figures, and can
>> get quite large. I've also created an overview for the editor using a
>> ScrollableThumbnail.
>>
>> Things seem to work okay as long as the zoom in the editor is 1x.
>> However, if I zoom in several times with the thumbnail viewer open and do
>> a lot of navigation with my viewport, my workbench crashes with an
>> SWTError (stack trace below).
>>
>> I think that there is a problem with the way that the Thumbnail is
>> disposing of images. I have a feeling that not all of them are being
>> properly disposed. I'm wondering if anyone else is having this problem?
>>
>> Error while informing user about event loop exception:
>> org.eclipse.swt.SWTError: No more handles
>> at org.eclipse.swt.SWT.error(SWT.java:3400)
>> at org.eclipse.swt.SWT.error(SWT.java:3297)
>> at org.eclipse.swt.SWT.error(SWT.java:3268)
>> at org.eclipse.swt.graphics.Image.internal_new_GC(Image.java:19 35)
>> at org.eclipse.swt.graphics.GC.<init>(GC.java:132)
>> at
>> org.eclipse.draw2d.BufferedGraphicsSource.getGraphics(Buffer edGraphicsSource.java:106)
>> at
>> org.eclipse.draw2d.DeferredUpdateManager.getGraphics(Deferre dUpdateManager.java:135)
>> at
>> org.eclipse.draw2d.DeferredUpdateManager.repairDamage(Deferr edUpdateManager.java:272)
>> at
>> org.eclipse.draw2d.DeferredUpdateManager.performUpdate(Defer redUpdateManager.java:167)
>> at
>> org.eclipse.draw2d.DeferredUpdateManager$UpdateRequest.run(D eferredUpdateManager.java:46)
>> at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:3 5)
>> at
>> org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchr onizer.java:123)
>> at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.jav a:3325)
>> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :2971)
>> at
>> org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:1930)
>> at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1894)
>> at
>> org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Work bench.java:422)
>> at
>> org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.j ava:149)
>> at
>> org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplicatio n.java:95)
>> at
>> org.eclipse.core.internal.runtime.PlatformActivator$1.run(Pl atformActivator.java:78)
>> at
>> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .runApplication(EclipseAppLauncher.java:92)
>> at
>> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .start(EclipseAppLauncher.java:68)
>> at
>> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:400)
>> at
>> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:177)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce ssorImpl.java:39)
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe thodAccessorImpl.java:25)
>> at java.lang.reflect.Method.invoke(Method.java:597)
>> at org.eclipse.core.launcher.Main.invokeFramework(Main.java:336 )
>> at org.eclipse.core.launcher.Main.basicRun(Main.java:280)
>> at org.eclipse.core.launcher.Main.run(Main.java:977)
>> at org.eclipse.core.launcher.Main.main(Main.java:952)
>> Dialog open exception:
>> org.eclipse.swt.SWTException: Unsupported color depth
>> at org.eclipse.swt.SWT.error(SWT.java:3374)
>> at org.eclipse.swt.SWT.error(SWT.java:3297)
>> at org.eclipse.swt.SWT.error(SWT.java:3268)
>> at org.eclipse.swt.graphics.Image.getImageData(Image.java:1232)
>> at
>> org.eclipse.swt.widgets.Decorations.setImages(Decorations.ja va:917)
>> at
>> org.eclipse.swt.widgets.Decorations.setImages(Decorations.ja va:1000)
>> at org.eclipse.jface.window.Window.configureShell(Window.java:3 68)
>> at
>> org.eclipse.jface.dialogs.MessageDialog.configureShell(Messa geDialog.java:175)
>> at org.eclipse.jface.window.Window.createShell(Window.java:497)
>> at org.eclipse.jface.window.Window.create(Window.java:425)
>> at org.eclipse.jface.dialogs.Dialog.create(Dialog.java:1124)
>> at
>> org.eclipse.ui.internal.ide.dialogs.InternalErrorDialog.open (InternalErrorDialog.java:74)
>> at
>> org.eclipse.ui.internal.ide.dialogs.InternalErrorDialog.open Question(InternalErrorDialog.java:185)
>> at
>> org.eclipse.ui.internal.ide.IDEExceptionHandler.openQuestion Dialog(IDEExceptionHandler.java:174)
>> at
>> org.eclipse.ui.internal.ide.IDEExceptionHandler.handleExcept ion(IDEExceptionHandler.java:100)
>> at
>> org.eclipse.ui.internal.ide.IDEWorkbenchAdvisor.eventLoopExc eption(IDEWorkbenchAdvisor.java:298)
>> at
>> org.eclipse.ui.internal.ExceptionHandler.handleException(Exc eptionHandler.java:62)
>> at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:1934)
>> at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1894)
>> at
>> org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Work bench.java:422)
>> at
>> org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.j ava:149)
>> at
>> org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplicatio n.java:95)
>> at
>> org.eclipse.core.internal.runtime.PlatformActivator$1.run(Pl atformActivator.java:78)
>> at
>> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .runApplication(EclipseAppLauncher.java:92)
>> at
>> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .start(EclipseAppLauncher.java:68)
>> at
>> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:400)
>> at
>> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:177)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce ssorImpl.java:39)
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe thodAccessorImpl.java:25)
>> at java.lang.reflect.Method.invoke(Method.java:597)
>> at org.eclipse.core.launcher.Main.invokeFramework(Main.java:336 )
>> at org.eclipse.core.launcher.Main.basicRun(Main.java:280)
>> at org.eclipse.core.launcher.Main.run(Main.java:977)
>> at org.eclipse.core.launcher.Main.main(Main.java:952)
|
|
|
| Re: No more handles when using ScrollableThumbnail [message #232548 is a reply to message #232414] |
Mon, 02 April 2007 18:52 |
Del Myers
Messages: 82
Registered: July 2009 |
Member |
|
|
The problem isn't with the GC in the Thumbnail, it is with the GCs used in the
paint process in the update manager, I believe. Every time a paint is called a
new GC gets created for the figure. The ThumbnailUpdater calls repaint() in the
run() method potentially thousands, or tens-of-thousands (as in my case) of
times depending on how large the source figure is. Eventually this translates
into thousands of new GCs getting created when the paint is done for the figure.
Not all at once, mind you, but in quick succession. I just don't think that the
OS is freeing up the resources quick enough (though they eventually get freed as
far as I can tell).
And there shouldn't be a resource leak in my figure's paint method because I'm
not writing any of my own paint methods. All of my figures are just regular old
rectangles, labels, connections, viewports, or compositions of those. So, unless
the RectangleFigure has a leak in its paint method, there shouldn't be a problem
there.
Randy Hudson wrote:
> This code is pretty mature (meaning I can't remember how it works), but it
> seems like it only creates one GC for the entire pass through the source
> figure. You might have a resource leak in your figure's paint methods
> somewhere.
>
> "Del Myers" <delmyers.cs@gmail.com> wrote in message
> news:eu96e8$qoo$1@utils.eclipse.org...
>> I think that I may have found the problem:
>>
>> In the Thumbnail class, there is a method
>> ThumnailUpdater.resetTileValues() which sets the number of tiles for the
>> redraw based on the size of the source figure and the maximum buffer size
>> (256x256 pixels). In most cases, this is fine, but I'm ending up with
>> absolutely massive charts. When I get massive charts, I can get in excess
>> of 10 000-20 000 tiles per redraw. All of the gcs for the draw are
>> disposed properly, but 20 000 gcs is, I suppose, just too much for the OS
>> to create and destroy in a short period of time.
>>
>> I've come up with a solution which is to create a patched version of
>> Thumbnail which limits the number of tiles that can be created.
>> Unfortunately, that makes the memory footprint a lot larger. But, if
>> people are looking at huge graphs, they are going to need a lot of memory
>> anyway.
>>
>> I think that this will work.
>>
>> Del Myers wrote:
>>> I've created a GEF editor that may contain thousands of figures, and can
>>> get quite large. I've also created an overview for the editor using a
>>> ScrollableThumbnail.
>>>
>>> Things seem to work okay as long as the zoom in the editor is 1x.
>>> However, if I zoom in several times with the thumbnail viewer open and do
>>> a lot of navigation with my viewport, my workbench crashes with an
>>> SWTError (stack trace below).
>>>
>>> I think that there is a problem with the way that the Thumbnail is
>>> disposing of images. I have a feeling that not all of them are being
>>> properly disposed. I'm wondering if anyone else is having this problem?
>>>
>>> Error while informing user about event loop exception:
>>> org.eclipse.swt.SWTError: No more handles
>>> at org.eclipse.swt.SWT.error(SWT.java:3400)
>>> at org.eclipse.swt.SWT.error(SWT.java:3297)
>>> at org.eclipse.swt.SWT.error(SWT.java:3268)
>>> at org.eclipse.swt.graphics.Image.internal_new_GC(Image.java:19 35)
>>> at org.eclipse.swt.graphics.GC.<init>(GC.java:132)
>>> at
>>> org.eclipse.draw2d.BufferedGraphicsSource.getGraphics(Buffer edGraphicsSource.java:106)
>>> at
>>> org.eclipse.draw2d.DeferredUpdateManager.getGraphics(Deferre dUpdateManager.java:135)
>>> at
>>> org.eclipse.draw2d.DeferredUpdateManager.repairDamage(Deferr edUpdateManager.java:272)
>>> at
>>> org.eclipse.draw2d.DeferredUpdateManager.performUpdate(Defer redUpdateManager.java:167)
>>> at
>>> org.eclipse.draw2d.DeferredUpdateManager$UpdateRequest.run(D eferredUpdateManager.java:46)
>>> at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:3 5)
>>> at
>>> org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchr onizer.java:123)
>>> at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.jav a:3325)
>>> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :2971)
>>> at
>>> org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:1930)
>>> at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1894)
>>> at
>>> org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Work bench.java:422)
>>> at
>>> org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.j ava:149)
>>> at
>>> org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplicatio n.java:95)
>>> at
>>> org.eclipse.core.internal.runtime.PlatformActivator$1.run(Pl atformActivator.java:78)
>>> at
>>> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .runApplication(EclipseAppLauncher.java:92)
>>> at
>>> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .start(EclipseAppLauncher.java:68)
>>> at
>>> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:400)
>>> at
>>> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:177)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce ssorImpl.java:39)
>>> at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe thodAccessorImpl.java:25)
>>> at java.lang.reflect.Method.invoke(Method.java:597)
>>> at org.eclipse.core.launcher.Main.invokeFramework(Main.java:336 )
>>> at org.eclipse.core.launcher.Main.basicRun(Main.java:280)
>>> at org.eclipse.core.launcher.Main.run(Main.java:977)
>>> at org.eclipse.core.launcher.Main.main(Main.java:952)
>>> Dialog open exception:
>>> org.eclipse.swt.SWTException: Unsupported color depth
>>> at org.eclipse.swt.SWT.error(SWT.java:3374)
>>> at org.eclipse.swt.SWT.error(SWT.java:3297)
>>> at org.eclipse.swt.SWT.error(SWT.java:3268)
>>> at org.eclipse.swt.graphics.Image.getImageData(Image.java:1232)
>>> at
>>> org.eclipse.swt.widgets.Decorations.setImages(Decorations.ja va:917)
>>> at
>>> org.eclipse.swt.widgets.Decorations.setImages(Decorations.ja va:1000)
>>> at org.eclipse.jface.window.Window.configureShell(Window.java:3 68)
>>> at
>>> org.eclipse.jface.dialogs.MessageDialog.configureShell(Messa geDialog.java:175)
>>> at org.eclipse.jface.window.Window.createShell(Window.java:497)
>>> at org.eclipse.jface.window.Window.create(Window.java:425)
>>> at org.eclipse.jface.dialogs.Dialog.create(Dialog.java:1124)
>>> at
>>> org.eclipse.ui.internal.ide.dialogs.InternalErrorDialog.open (InternalErrorDialog.java:74)
>>> at
>>> org.eclipse.ui.internal.ide.dialogs.InternalErrorDialog.open Question(InternalErrorDialog.java:185)
>>> at
>>> org.eclipse.ui.internal.ide.IDEExceptionHandler.openQuestion Dialog(IDEExceptionHandler.java:174)
>>> at
>>> org.eclipse.ui.internal.ide.IDEExceptionHandler.handleExcept ion(IDEExceptionHandler.java:100)
>>> at
>>> org.eclipse.ui.internal.ide.IDEWorkbenchAdvisor.eventLoopExc eption(IDEWorkbenchAdvisor.java:298)
>>> at
>>> org.eclipse.ui.internal.ExceptionHandler.handleException(Exc eptionHandler.java:62)
>>> at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:1934)
>>> at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1894)
>>> at
>>> org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Work bench.java:422)
>>> at
>>> org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.j ava:149)
>>> at
>>> org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplicatio n.java:95)
>>> at
>>> org.eclipse.core.internal.runtime.PlatformActivator$1.run(Pl atformActivator.java:78)
>>> at
>>> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .runApplication(EclipseAppLauncher.java:92)
>>> at
>>> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .start(EclipseAppLauncher.java:68)
>>> at
>>> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:400)
>>> at
>>> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:177)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce ssorImpl.java:39)
>>> at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe thodAccessorImpl.java:25)
>>> at java.lang.reflect.Method.invoke(Method.java:597)
>>> at org.eclipse.core.launcher.Main.invokeFramework(Main.java:336 )
>>> at org.eclipse.core.launcher.Main.basicRun(Main.java:280)
>>> at org.eclipse.core.launcher.Main.run(Main.java:977)
>>> at org.eclipse.core.launcher.Main.main(Main.java:952)
>
>
|
|
|
| Re: No more handles when using ScrollableThumbnail [message #232594 is a reply to message #232548] |
Tue, 03 April 2007 11:09 |
| Eclipse User |
|
|
|
Originally posted by: neerajkarandikar.gmail.com
Hi Del,
I faced this same problem few days back, and i found out problem was mainly
in my code and not in the GEF framework.
If it helps you should know that Windows allows only 10K UI handles to be
created which causes this problem of running out of handles.
Some of the problems areas i had were:
1. Mutliple instances of GC being created in my code
2. To many Images being created for similer figures
Ex. i used to create new Image instances each time i needed a
Figure; which caused thousands of images being created each time things are
layed out.
I used ImageRegistry to minimize the no. of images being created.
3. Repeatative creation of Font and Color instances in case of Labels
- Either use static font and color instances... or create FontRegistry
I hope this helps.
Regards,
-Neeraj
"Del Myers" <delmyers.cs@gmail.com> wrote in message
news:eurjc7$kei$1@build.eclipse.org...
> The problem isn't with the GC in the Thumbnail, it is with the GCs used in
> the paint process in the update manager, I believe. Every time a paint is
> called a new GC gets created for the figure. The ThumbnailUpdater calls
> repaint() in the run() method potentially thousands, or tens-of-thousands
> (as in my case) of times depending on how large the source figure is.
> Eventually this translates into thousands of new GCs getting created when
> the paint is done for the figure. Not all at once, mind you, but in quick
> succession. I just don't think that the OS is freeing up the resources
> quick enough (though they eventually get freed as far as I can tell).
>
> And there shouldn't be a resource leak in my figure's paint method because
> I'm not writing any of my own paint methods. All of my figures are just
> regular old rectangles, labels, connections, viewports, or compositions of
> those. So, unless the RectangleFigure has a leak in its paint method,
> there shouldn't be a problem there.
>
> Randy Hudson wrote:
>> This code is pretty mature (meaning I can't remember how it works), but
>> it seems like it only creates one GC for the entire pass through the
>> source figure. You might have a resource leak in your figure's paint
>> methods somewhere.
>>
>> "Del Myers" <delmyers.cs@gmail.com> wrote in message
>> news:eu96e8$qoo$1@utils.eclipse.org...
>>> I think that I may have found the problem:
>>>
>>> In the Thumbnail class, there is a method
>>> ThumnailUpdater.resetTileValues() which sets the number of tiles for the
>>> redraw based on the size of the source figure and the maximum buffer
>>> size (256x256 pixels). In most cases, this is fine, but I'm ending up
>>> with absolutely massive charts. When I get massive charts, I can get in
>>> excess of 10 000-20 000 tiles per redraw. All of the gcs for the draw
>>> are disposed properly, but 20 000 gcs is, I suppose, just too much for
>>> the OS to create and destroy in a short period of time.
>>>
>>> I've come up with a solution which is to create a patched version of
>>> Thumbnail which limits the number of tiles that can be created.
>>> Unfortunately, that makes the memory footprint a lot larger. But, if
>>> people are looking at huge graphs, they are going to need a lot of
>>> memory anyway.
>>>
>>> I think that this will work.
>>>
>>> Del Myers wrote:
>>>> I've created a GEF editor that may contain thousands of figures, and
>>>> can get quite large. I've also created an overview for the editor using
>>>> a ScrollableThumbnail.
>>>>
>>>> Things seem to work okay as long as the zoom in the editor is 1x.
>>>> However, if I zoom in several times with the thumbnail viewer open and
>>>> do a lot of navigation with my viewport, my workbench crashes with an
>>>> SWTError (stack trace below).
>>>>
>>>> I think that there is a problem with the way that the Thumbnail is
>>>> disposing of images. I have a feeling that not all of them are being
>>>> properly disposed. I'm wondering if anyone else is having this problem?
>>>>
>>>> Error while informing user about event loop exception:
>>>> org.eclipse.swt.SWTError: No more handles
>>>> at org.eclipse.swt.SWT.error(SWT.java:3400)
>>>> at org.eclipse.swt.SWT.error(SWT.java:3297)
>>>> at org.eclipse.swt.SWT.error(SWT.java:3268)
>>>> at org.eclipse.swt.graphics.Image.internal_new_GC(Image.java:19 35)
>>>> at org.eclipse.swt.graphics.GC.<init>(GC.java:132)
>>>> at
>>>> org.eclipse.draw2d.BufferedGraphicsSource.getGraphics(Buffer edGraphicsSource.java:106)
>>>> at
>>>> org.eclipse.draw2d.DeferredUpdateManager.getGraphics(Deferre dUpdateManager.java:135)
>>>> at
>>>> org.eclipse.draw2d.DeferredUpdateManager.repairDamage(Deferr edUpdateManager.java:272)
>>>> at
>>>> org.eclipse.draw2d.DeferredUpdateManager.performUpdate(Defer redUpdateManager.java:167)
>>>> at
>>>> org.eclipse.draw2d.DeferredUpdateManager$UpdateRequest.run(D eferredUpdateManager.java:46)
>>>> at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:3 5)
>>>> at
>>>> org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchr onizer.java:123)
>>>> at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.jav a:3325)
>>>> at
>>>> org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :2971)
>>>> at
>>>> org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:1930)
>>>> at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1894)
>>>> at
>>>> org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Work bench.java:422)
>>>> at
>>>> org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.j ava:149)
>>>> at
>>>> org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplicatio n.java:95)
>>>> at
>>>> org.eclipse.core.internal.runtime.PlatformActivator$1.run(Pl atformActivator.java:78)
>>>> at
>>>> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .runApplication(EclipseAppLauncher.java:92)
>>>> at
>>>> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .start(EclipseAppLauncher.java:68)
>>>> at
>>>> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:400)
>>>> at
>>>> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:177)
>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>> at
>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce ssorImpl.java:39)
>>>> at
>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe thodAccessorImpl.java:25)
>>>> at java.lang.reflect.Method.invoke(Method.java:597)
>>>> at org.eclipse.core.launcher.Main.invokeFramework(Main.java:336 )
>>>> at org.eclipse.core.launcher.Main.basicRun(Main.java:280)
>>>> at org.eclipse.core.launcher.Main.run(Main.java:977)
>>>> at org.eclipse.core.launcher.Main.main(Main.java:952)
>>>> Dialog open exception:
>>>> org.eclipse.swt.SWTException: Unsupported color depth
>>>> at org.eclipse.swt.SWT.error(SWT.java:3374)
>>>> at org.eclipse.swt.SWT.error(SWT.java:3297)
>>>> at org.eclipse.swt.SWT.error(SWT.java:3268)
>>>> at org.eclipse.swt.graphics.Image.getImageData(Image.java:1232)
>>>> at
>>>> org.eclipse.swt.widgets.Decorations.setImages(Decorations.ja va:917)
>>>> at
>>>> org.eclipse.swt.widgets.Decorations.setImages(Decorations.ja va:1000)
>>>> at org.eclipse.jface.window.Window.configureShell(Window.java:3 68)
>>>> at
>>>> org.eclipse.jface.dialogs.MessageDialog.configureShell(Messa geDialog.java:175)
>>>> at org.eclipse.jface.window.Window.createShell(Window.java:497)
>>>> at org.eclipse.jface.window.Window.create(Window.java:425)
>>>> at org.eclipse.jface.dialogs.Dialog.create(Dialog.java:1124)
>>>> at
>>>> org.eclipse.ui.internal.ide.dialogs.InternalErrorDialog.open (InternalErrorDialog.java:74)
>>>> at
>>>> org.eclipse.ui.internal.ide.dialogs.InternalErrorDialog.open Question(InternalErrorDialog.java:185)
>>>> at
>>>> org.eclipse.ui.internal.ide.IDEExceptionHandler.openQuestion Dialog(IDEExceptionHandler.java:174)
>>>> at
>>>> org.eclipse.ui.internal.ide.IDEExceptionHandler.handleExcept ion(IDEExceptionHandler.java:100)
>>>> at
>>>> org.eclipse.ui.internal.ide.IDEWorkbenchAdvisor.eventLoopExc eption(IDEWorkbenchAdvisor.java:298)
>>>> at
>>>> org.eclipse.ui.internal.ExceptionHandler.handleException(Exc eptionHandler.java:62)
>>>> at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:1934)
>>>> at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1894)
>>>> at
>>>> org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Work bench.java:422)
>>>> at
>>>> org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.j ava:149)
>>>> at
>>>> org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplicatio n.java:95)
>>>> at
>>>> org.eclipse.core.internal.runtime.PlatformActivator$1.run(Pl atformActivator.java:78)
>>>> at
>>>> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .runApplication(EclipseAppLauncher.java:92)
>>>> at
>>>> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .start(EclipseAppLauncher.java:68)
>>>> at
>>>> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:400)
>>>> at
>>>> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:177)
>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>> at
>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce ssorImpl.java:39)
>>>> at
>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe thodAccessorImpl.java:25)
>>>> at java.lang.reflect.Method.invoke(Method.java:597)
>>>> at org.eclipse.core.launcher.Main.invokeFramework(Main.java:336 )
>>>> at org.eclipse.core.launcher.Main.basicRun(Main.java:280)
>>>> at org.eclipse.core.launcher.Main.run(Main.java:977)
>>>> at org.eclipse.core.launcher.Main.main(Main.java:952)
>>
|
|
|
| Re: No more handles when using ScrollableThumbnail [message #232622 is a reply to message #232594] |
Tue, 03 April 2007 16:28 |
Del Myers
Messages: 82
Registered: July 2009 |
Member |
|
|
Like I said, there are none of these problems in my code. I don't create any
GCs, Fonts, Images, etc. I just draw boxes and lines. The problem was solved
after I increased the allowable size of the tiles in the Thumbnail figure.
There may be a problem in that the view that I created uses draw2d as an
underlying "graphics engine", but uses SWT patterns for creating the chart. I.e.
you create a widget for each box, connection, etc. And there could be thousands
of boxes. But, then again, I don't know if any handles are created for simple
bare-bones custom widgets (they don't do any drawing, have any GCs, create any
fonts), and I never had any problem until I started using the Thumbnail figure.
I agree that the Thumbnail code looks pretty solid, as does the rest of draw2d.
But, the problem always occurred when a GC needed to be created for the update
in the update manager. Again, all the resources seemed to be getting disposed at
the right time in the Java end (I even added some code while I was debugging to
try and count when things were being disposed). I could do some deeper searching
for memory leaks using a profiler, I suppose, but as the problem looks to have
been solved from my original analysis, I don't see any need to.
Thanks for your input, though.
Del
neeraj wrote:
> Hi Del,
>
> I faced this same problem few days back, and i found out problem was mainly
> in my code and not in the GEF framework.
> If it helps you should know that Windows allows only 10K UI handles to be
> created which causes this problem of running out of handles.
>
> Some of the problems areas i had were:
> 1. Mutliple instances of GC being created in my code
>
> 2. To many Images being created for similer figures
> Ex. i used to create new Image instances each time i needed a
> Figure; which caused thousands of images being created each time things are
> layed out.
>
> I used ImageRegistry to minimize the no. of images being created.
>
> 3. Repeatative creation of Font and Color instances in case of Labels
> - Either use static font and color instances... or create FontRegistry
>
> I hope this helps.
> Regards,
> -Neeraj
>
> "Del Myers" <delmyers.cs@gmail.com> wrote in message
> news:eurjc7$kei$1@build.eclipse.org...
>> The problem isn't with the GC in the Thumbnail, it is with the GCs used in
>> the paint process in the update manager, I believe. Every time a paint is
>> called a new GC gets created for the figure. The ThumbnailUpdater calls
>> repaint() in the run() method potentially thousands, or tens-of-thousands
>> (as in my case) of times depending on how large the source figure is.
>> Eventually this translates into thousands of new GCs getting created when
>> the paint is done for the figure. Not all at once, mind you, but in quick
>> succession. I just don't think that the OS is freeing up the resources
>> quick enough (though they eventually get freed as far as I can tell).
>>
>> And there shouldn't be a resource leak in my figure's paint method because
>> I'm not writing any of my own paint methods. All of my figures are just
>> regular old rectangles, labels, connections, viewports, or compositions of
>> those. So, unless the RectangleFigure has a leak in its paint method,
>> there shouldn't be a problem there.
>>
>> Randy Hudson wrote:
>>> This code is pretty mature (meaning I can't remember how it works), but
>>> it seems like it only creates one GC for the entire pass through the
>>> source figure. You might have a resource leak in your figure's paint
>>> methods somewhere.
>>>
>>> "Del Myers" <delmyers.cs@gmail.com> wrote in message
>>> news:eu96e8$qoo$1@utils.eclipse.org...
>>>> I think that I may have found the problem:
>>>>
>>>> In the Thumbnail class, there is a method
>>>> ThumnailUpdater.resetTileValues() which sets the number of tiles for the
>>>> redraw based on the size of the source figure and the maximum buffer
>>>> size (256x256 pixels). In most cases, this is fine, but I'm ending up
>>>> with absolutely massive charts. When I get massive charts, I can get in
>>>> excess of 10 000-20 000 tiles per redraw. All of the gcs for the draw
>>>> are disposed properly, but 20 000 gcs is, I suppose, just too much for
>>>> the OS to create and destroy in a short period of time.
>>>>
>>>> I've come up with a solution which is to create a patched version of
>>>> Thumbnail which limits the number of tiles that can be created.
>>>> Unfortunately, that makes the memory footprint a lot larger. But, if
>>>> people are looking at huge graphs, they are going to need a lot of
>>>> memory anyway.
>>>>
>>>> I think that this will work.
>>>>
>>>> Del Myers wrote:
>>>>> I've created a GEF editor that may contain thousands of figures, and
>>>>> can get quite large. I've also created an overview for the editor using
>>>>> a ScrollableThumbnail.
>>>>>
>>>>> Things seem to work okay as long as the zoom in the editor is 1x.
>>>>> However, if I zoom in several times with the thumbnail viewer open and
>>>>> do a lot of navigation with my viewport, my workbench crashes with an
>>>>> SWTError (stack trace below).
>>>>>
>>>>> I think that there is a problem with the way that the Thumbnail is
>>>>> disposing of images. I have a feeling that not all of them are being
>>>>> properly disposed. I'm wondering if anyone else is having this problem?
>>>>>
>>>>> Error while informing user about event loop exception:
>>>>> org.eclipse.swt.SWTError: No more handles
>>>>> at org.eclipse.swt.SWT.error(SWT.java:3400)
>>>>> at org.eclipse.swt.SWT.error(SWT.java:3297)
>>>>> at org.eclipse.swt.SWT.error(SWT.java:3268)
>>>>> at org.eclipse.swt.graphics.Image.internal_new_GC(Image.java:19 35)
>>>>> at org.eclipse.swt.graphics.GC.<init>(GC.java:132)
>>>>> at
>>>>> org.eclipse.draw2d.BufferedGraphicsSource.getGraphics(Buffer edGraphicsSource.java:106)
>>>>> at
>>>>> org.eclipse.draw2d.DeferredUpdateManager.getGraphics(Deferre dUpdateManager.java:135)
>>>>> at
>>>>> org.eclipse.draw2d.DeferredUpdateManager.repairDamage(Deferr edUpdateManager.java:272)
>>>>> at
>>>>> org.eclipse.draw2d.DeferredUpdateManager.performUpdate(Defer redUpdateManager.java:167)
>>>>> at
>>>>> org.eclipse.draw2d.DeferredUpdateManager$UpdateRequest.run(D eferredUpdateManager.java:46)
>>>>> at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:3 5)
>>>>> at
>>>>> org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchr onizer.java:123)
>>>>> at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.jav a:3325)
>>>>> at
>>>>> org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :2971)
>>>>> at
>>>>> org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:1930)
>>>>> at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1894)
>>>>> at
>>>>> org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Work bench.java:422)
>>>>> at
>>>>> org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.j ava:149)
>>>>> at
>>>>> org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplicatio n.java:95)
>>>>> at
>>>>> org.eclipse.core.internal.runtime.PlatformActivator$1.run(Pl atformActivator.java:78)
>>>>> at
>>>>> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .runApplication(EclipseAppLauncher.java:92)
>>>>> at
>>>>> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .start(EclipseAppLauncher.java:68)
>>>>> at
>>>>> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:400)
>>>>> at
>>>>> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:177)
>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>> at
>>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce ssorImpl.java:39)
>>>>> at
>>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe thodAccessorImpl.java:25)
>>>>> at java.lang.reflect.Method.invoke(Method.java:597)
>>>>> at org.eclipse.core.launcher.Main.invokeFramework(Main.java:336 )
>>>>> at org.eclipse.core.launcher.Main.basicRun(Main.java:280)
>>>>> at org.eclipse.core.launcher.Main.run(Main.java:977)
>>>>> at org.eclipse.core.launcher.Main.main(Main.java:952)
>>>>> Dialog open exception:
>>>>> org.eclipse.swt.SWTException: Unsupported color depth
>>>>> at org.eclipse.swt.SWT.error(SWT.java:3374)
>>>>> at org.eclipse.swt.SWT.error(SWT.java:3297)
>>>>> at org.eclipse.swt.SWT.error(SWT.java:3268)
>>>>> at org.eclipse.swt.graphics.Image.getImageData(Image.java:1232)
>>>>> at
>>>>> org.eclipse.swt.widgets.Decorations.setImages(Decorations.ja va:917)
>>>>> at
>>>>> org.eclipse.swt.widgets.Decorations.setImages(Decorations.ja va:1000)
>>>>> at org.eclipse.jface.window.Window.configureShell(Window.java:3 68)
>>>>> at
>>>>> org.eclipse.jface.dialogs.MessageDialog.configureShell(Messa geDialog.java:175)
>>>>> at org.eclipse.jface.window.Window.createShell(Window.java:497)
>>>>> at org.eclipse.jface.window.Window.create(Window.java:425)
>>>>> at org.eclipse.jface.dialogs.Dialog.create(Dialog.java:1124)
>>>>> at
>>>>> org.eclipse.ui.internal.ide.dialogs.InternalErrorDialog.open (InternalErrorDialog.java:74)
>>>>> at
>>>>> org.eclipse.ui.internal.ide.dialogs.InternalErrorDialog.open Question(InternalErrorDialog.java:185)
>>>>> at
>>>>> org.eclipse.ui.internal.ide.IDEExceptionHandler.openQuestion Dialog(IDEExceptionHandler.java:174)
>>>>> at
>>>>> org.eclipse.ui.internal.ide.IDEExceptionHandler.handleExcept ion(IDEExceptionHandler.java:100)
>>>>> at
>>>>> org.eclipse.ui.internal.ide.IDEWorkbenchAdvisor.eventLoopExc eption(IDEWorkbenchAdvisor.java:298)
>>>>> at
>>>>> org.eclipse.ui.internal.ExceptionHandler.handleException(Exc eptionHandler.java:62)
>>>>> at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:1934)
>>>>> at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1894)
>>>>> at
>>>>> org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Work bench.java:422)
>>>>> at
>>>>> org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.j ava:149)
>>>>> at
>>>>> org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplicatio n.java:95)
>>>>> at
>>>>> org.eclipse.core.internal.runtime.PlatformActivator$1.run(Pl atformActivator.java:78)
>>>>> at
>>>>> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .runApplication(EclipseAppLauncher.java:92)
>>>>> at
>>>>> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .start(EclipseAppLauncher.java:68)
>>>>> at
>>>>> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:400)
>>>>> at
>>>>> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:177)
>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>> at
>>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce ssorImpl.java:39)
>>>>> at
>>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe thodAccessorImpl.java:25)
>>>>> at java.lang.reflect.Method.invoke(Method.java:597)
>>>>> at org.eclipse.core.launcher.Main.invokeFramework(Main.java:336 )
>>>>> at org.eclipse.core.launcher.Main.basicRun(Main.java:280)
>>>>> at org.eclipse.core.launcher.Main.run(Main.java:977)
>>>>> at org.eclipse.core.launcher.Main.main(Main.java:952)
>
|
|
|
Goto Forum:
Current Time: Fri Apr 19 16:44:53 GMT 2024
Powered by FUDForum. Page generated in 0.02090 seconds |
] 
Search
Help
Register
Login
Home
