Developer Crashes..

Classic Servoy
1

HI,
I am experiencing Crashes in Servoy Developer 7.3.1… It seems to be when I am working with globals.js… my os is Windows 7 64bit, the following is written in the Workspace .metadata .log, it is becoming really painful and ideas/help would be great!

!SESSION 2014-02-18 15:59:11.914 -----------------------------------------------
eclipse.buildId=unknown
java.version=1.6.0_27
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_AU
Command-line arguments: -os win32 -ws win32 -arch x86_64

This is a continuation of log file C:\Users\proutley\Workspaces\Austube_Prodution_73.metadata.bak_0.log
Created Time: 2014-02-18 16:22:11.585

!ENTRY org.eclipse.ui 4 4 2014-02-18 16:22:11.586
!MESSAGE An internal error has occurred.
!STACK 0
org.eclipse.swt.SWTError: No more handles
at org.eclipse.swt.SWT.error(SWT.java:4308)
at org.eclipse.swt.SWT.error(SWT.java:4197)
at org.eclipse.swt.SWT.error(SWT.java:4168)
at org.eclipse.swt.widgets.Display.internal_new_GC(Display.java:2673)
at org.eclipse.swt.graphics.Device.getDepth(Device.java:447)
at org.eclipse.swt.custom.CTabFolder.setSelectionBackground(CTabFolder.java:2861)
at org.eclipse.ui.internal.presentations.PaneFolder.setSelectionBackground(PaneFolder.java:772)
at org.eclipse.ui.internal.presentations.defaultpresentation.DefaultTabFolder.updateColors(DefaultTabFolder.java:468)
at org.eclipse.ui.internal.presentations.defaultpresentation.DefaultTabFolder.setActive(DefaultTabFolder.java:420)
at org.eclipse.ui.internal.presentations.util.TabbedStackPresentation.setActive(TabbedStackPresentation.java:372)
at org.eclipse.ui.internal.DefaultStackPresentationSite.setActive(DefaultStackPresentationSite.java:55)
at org.eclipse.ui.internal.PartStack.setActive(PartStack.java:1174)
at org.eclipse.ui.internal.EditorPane.showFocus(EditorPane.java:140)
at org.eclipse.ui.internal.WorkbenchPage.deactivatePart(WorkbenchPage.java:1807)
at org.eclipse.ui.internal.WorkbenchPage.setActivePart(WorkbenchPage.java:3622)
at org.eclipse.ui.internal.WorkbenchPage.makeActive(WorkbenchPage.java:1318)
at org.eclipse.ui.internal.WorkbenchPage.onDeactivate(WorkbenchPage.java:2724)
at org.eclipse.ui.internal.WorkbenchWindow$28.run(WorkbenchWindow.java:3016)
at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
at org.eclipse.ui.internal.WorkbenchWindow.setActivePage(WorkbenchWindow.java:3011)
at org.eclipse.ui.internal.WorkbenchWindow.closeAllPages(WorkbenchWindow.java:882)
at org.eclipse.ui.internal.WorkbenchWindow.hardClose(WorkbenchWindow.java:1729)
at org.eclipse.ui.internal.WorkbenchWindow.busyClose(WorkbenchWindow.java:730)
at org.eclipse.ui.internal.WorkbenchWindow.access$0(WorkbenchWindow.java:715)
at org.eclipse.ui.internal.WorkbenchWindow$6.run(WorkbenchWindow.java:867)
at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
at org.eclipse.ui.internal.WorkbenchWindow.close(WorkbenchWindow.java:865)
at org.eclipse.jface.window.WindowManager.close(WindowManager.java:109)
at org.eclipse.ui.internal.Workbench$18.run(Workbench.java:1114)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.ui.internal.Workbench.busyClose(Workbench.java:1111)
at org.eclipse.ui.internal.Workbench.access$15(Workbench.java:1040)
at org.eclipse.ui.internal.Workbench$25.run(Workbench.java:1284)
at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
at org.eclipse.ui.internal.Workbench.close(Workbench.java:1282)
at org.eclipse.ui.internal.WorkbenchConfigurer.emergencyClose(WorkbenchConfigurer.java:165)
at org.eclipse.ui.internal.ide.IDEWorkbenchErrorHandler.closeWorkbench(IDEWorkbenchErrorHandler.java:253)
at org.eclipse.ui.internal.ide.IDEWorkbenchErrorHandler.handleException(IDEWorkbenchErrorHandler.java:155)
at org.eclipse.ui.internal.ide.IDEWorkbenchErrorHandler.access$0(IDEWorkbenchErrorHandler.java:146)
at org.eclipse.ui.internal.ide.IDEWorkbenchErrorHandler$1.runInUIThread(IDEWorkbenchErrorHandler.java:121)
at org.eclipse.ui.progress.UIJob$1.run(UIJob.java:95)
at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135)
at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4140)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3757)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2701)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2665)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2499)
at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:679)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:668)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:123)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
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.equinox.launcher.Main.invokeFramework(Main.java:622)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577)
at org.eclipse.equinox.launcher.Main.run(Main.java:1410)
at org.eclipse.equinox.launcher.Main.main(Main.java:1386)

2

Philip,

We experience the same thing daily. I have actually been logging the time it takes for us to restart Servoy Developer and get back to coding across our team. It takes on average 3 to 5 minutes for developer to start up and our solution to finish the build process. This happens to us (a team of 3) an average of 4 times each per day. Best case (assuming only a 3 minute restart time) that is 36 minutes/day wasted of development time or 3 man hours per week. VERY FRUSTRATING. Mind you, our solution is VERY large and we are pushing some limits when it comes to Java. So, with that said, here are some things we’ve done to try to help the situation a little bit and while they have helped a lot, they have not totally solved the problem;

  1. Modfiy the servoy.ini file in your Servoy Developer application folder (mine is c:\Servoy\developer.servoy.ini for instance) to look as follows:
-startup
plugins/org.eclipse.equinox.launcher_1.2.0.v20110502.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_64_1.1.100.v20110502
--launcher.XXMaxPermSize
512m
-vmargs
-Xms40m
-Xmx1024m
-XX:MaxPermSize=512M
  1. Modify the “Target:” field in the shortcut you use to open Servoy Developer as follows to give the path to the javaw executable:
C:\Servoy\developer\servoy.exe -vm "C:\Program Files\Java\jre7\bin\javaw.exe"

Item 2 I found in an obscure Eclipse forum somewhere and Item 1 Jason had helped me with about a year ago. Like I said, it has not solved the problem 100% but has reduced the number of times it crashes from about once every hour or so to a few times a day.

Best Regards,

Keith

3

Hi Keith,
Thank you I will give it a try …

4

no more handles is really a native resource problem
(running out of it)
its not directly a memory/heap problem

When this happens do you have a lot of editors open en that consume native resources?

because giving it more heap (Keith’s first suggestion i guess) doesn’t really help in “no more handles”
and also the second, pointing to a specific vm is i guess for most people only having 1 vm installed not really making any difference.

(i do use it myself but that is because i have many java jdk/jre’s installed including java6,7 and 8 )

But that “no more handles” could be a resource leak somewhere. But that can only be found if we can reproduce it somehow and attache a profiler to it that is able to track them
or maybe you are really hitting the operation systems maximum resources…

5

jcompagner:
When this happens do you have a lot of editors open en that consume native resources?

Hi Johan,

I’ve seen this happening on Windows (where else ;-)) when making changes to large (globals).js files.
If the building process hasn’t fully finished and you try for instance saving the file, this can result in an unresponsive Eclipse.
Force quit and restart is the only option after which you get these messages.

6

Hi Johan
I don’t normally have a lot of editors open, but as Marc mentioned it happens when I am working in globals.js, it seems to be fairly random, and hard to reproduce. Having said that it occurred twice today and both times I had to kill both the servoy.exe and java.exe processes in windows task manager. Which I thought was strange that both processes were still running in the background??, after the crash

7

the vm doesn’t crash, its just that inside the eclipse/servoy developer instance some exceptions happens (which is a quite serious exception) but the vm/process itself doesn’t crash for that.

8

So is there anything I can change settings wise to help the situation?

9

no not that i know of, except having something that we can setup here so that we can see it and reproduce it.

10

Ok Thanks Johan. It seems to settled down a little I will see how it goes.