[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Newsgroup Home]
|
[news.eclipse.platform.swt] Re: No more handles during startup of AGR test on Linux
|
Stop, I'm wrong! It is our application which dynamically creates menus! Two
requests, two menus even if they look identically. The menus need to be
disposed from within the application. In fact, AGR must not dispose
application menus. Hope, I didn't confuse anyone.
"Frank Froehlich" <ffr@xxxxxxxxxxxxxx> wrote in message
news:ejf0g1$cha$1@xxxxxxxxxxxxxxxxxxxx
> No, you're right here I think because I have the same problem.
>
> Does your test make extensive use of (context-) menus of the application
> (i.e. Plug-in) under test in your test scenario? What I found out is that
> AGR requires menus from the application under test but never disposes
> them. After applying a little code to BooleanSelectionCommand
> (package=org.eclipse.tptp.test.auto.gui.internal.commands) things go much
> better for me but are not perfect. The handle count still increases during
> test execution. It is very hard to find out all the places where the
> runner allocates resources without disposing them. I'll create a bugzilla
> entry for this.
>
>
> "Joel Rosi-Schwartz" <Joel.Rosi-Schwartz@xxxxxxxxx> wrote in message
> news:ejd700$ib6$2@xxxxxxxxxxxxxxxxxxxx
>> Hi,
>>
>> Sorry for the cross post, but it appears from the silence that perhaps I
>> chose the wrong newsgroup for my query.
>>
>> Thanks,
>> Joel
>>
>> Joel Rosi-Schwartz wrote:
>>> Hi,
>>>
>>> I am trying to get our test suites running under Linux. Since I am
>>> running RH Linux ES version 4 EM64T which is problematic for TPTP
>>> because the Agent Controller has not been ported yet, I have installed
>>> jdk-1_5_0_09-linux-i586 and eclipse-platform-3.2.1-linux-gtk, both 32
>>> bit implementations. On top of this I have installed the latest
>>> Callisto and org.eclipse.tptp.test.auto-TPTP-4.2.1. Everything
>>> appears to function properly until I attempt to run a test. Even a
>>> very basic newly recorded test that simply launches a workspace and
>>> creates a new project fails. The symptoms are that the test stalls at
>>> 60% and the eclipse never launches. Once I cancel it the log contains
>>> the following output. I understand the meaning running out of handles
>>> and the usual cause of not releasing resources. Since in the this case
>>> the Eclipse never gets on shown I scratch my head at exactly what
>>> resource can be exhausted yet.
>>>
>>> Thanks for your thoughts,
>>> Joel
>>>
>>> eclipse.buildId=M20060921-0945
>>> java.version=1.5.0_09
>>> java.vendor=Sun Microsystems Inc.
>>> BootLoader constants: OS=linux, ARCH=x86, WS=gtk, NL=en_US
>>> Command-line arguments: -data
>>> /home/joel/projects/Etish-32/../auto-gui-workspace
>>>
>>> !ENTRY org.eclipse.osgi 4 0 2006-11-11 11:55:14.099
>>> !MESSAGE Application error
>>> !STACK 1
>>> org.eclipse.swt.SWTError: No more handles [gtk_init_check() failed]
>>> at org.eclipse.swt.SWT.error(SWT.java:3400)
>>> at org.eclipse.swt.widgets.Display.createDisplay(Display.java:793)
>>> at org.eclipse.swt.widgets.Display.create(Display.java:781)
>>> at org.eclipse.swt.graphics.Device.<init>(Device.java:145)
>>> at org.eclipse.swt.widgets.Display.<init>(Display.java:452)
>>> at org.eclipse.swt.widgets.Display.<init>(Display.java:443)
>>> at
>>> org.eclipse.ui.internal.Workbench.createDisplay(Workbench.java:448)
>>> at org.eclipse.ui.PlatformUI.createDisplay(PlatformUI.java:161)
>>> at
>>>
>>> org.eclipse.ui.internal.ide.IDEApplication.createDisplay(IDEApplication.java:122)
>>> at
>>>
>>> org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:75)
>>> at
>>>
>>> org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.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(EclipseStarter.java:400)
>>> at
>>>
>>> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:177)
>>> 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:585)
>>> 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)
>>>
>>>
>>>
>>>
>>
>
>