If you have a memory dump you could place it on a location (zipped or better 7zipped) where i can download it. Then i can have a look
The stack i see there is just executing an onload method of a form that is being loaded in a tabpanel… That would be weird if that happens in a recursive thing because onload is only called once for an instance
So if that would really happen then somehow the soluton model touches and tries to destroy the form again somewhere in the onload of thet form?
The problem is also that if you are getting close to an out of mem then everything is really slow because of the full garbage collection cycles that are constantly happening.
jcompagner:
For the second error, we have 1 more report of this also on 6.1.2 or something. But we really don’t have any idea what that happens, we really need some use case when that happens
I had the same thing in my plain java eclipse yesterday also… But that was i guess running for quite a while and the only thing that could be the same is eclipse itself and the svn plugin i guess
that stack i see is that quite plain eclipse updating a Tree/TableViewer but that doesn’t say much why it happens.
I just got the same issue again - this time it was related to the code-completion feature listing the available forms, I also used a lot the Resource Locator dialog as well which in our case needs to work with tons of data.
david:
JS docs for functions in variables used to show up with code completion in Servoy 6.0.x. Code completion still works in 6.1.3 for objects defined this way but js docs are not retrieved.
Setting up objects this way is a wonderful way to expose an API with code completion and full documentation at the coder’s fingertips. Can we get this feature added back in?
On couple occasions I got the error during building of the solutions: “An internal error occurred during: “Building”. Could not initialize shell library”
This is from the Eclipse log:
!ENTRY org.eclipse.core.jobs 4 2 2012-12-17 10:48:49.016
!MESSAGE An internal error occurred during: "Building".
!STACK 0
java.lang.InternalError: Could not initialize shell library
at sun.awt.shell.Win32ShellFolder2.initIDs(Native Method)
at sun.awt.shell.Win32ShellFolder2.<clinit>(Unknown Source)
at sun.awt.shell.Win32ShellFolderManager2.get(Unknown Source)
at sun.awt.shell.ShellFolder.get(Unknown Source)
at com.sun.java.swing.plaf.windows.WindowsLookAndFeel$ActiveWindowsIcon.createValue(Unknown Source)
at javax.swing.UIDefaults.getFromHashtable(Unknown Source)
at javax.swing.UIDefaults.get(Unknown Source)
at javax.swing.MultiUIDefaults.get(Unknown Source)
at javax.swing.UIManager.get(Unknown Source)
at sun.swing.DefaultLookup.get(Unknown Source)
at sun.swing.DefaultLookup.getIcon(Unknown Source)
at sun.swing.DefaultLookup.getIcon(Unknown Source)
at javax.swing.tree.DefaultTreeCellRenderer.updateUI(Unknown Source)
at javax.swing.JLabel.<init>(Unknown Source)
at javax.swing.JLabel.<init>(Unknown Source)
at javax.swing.tree.DefaultTreeCellRenderer.<init>(Unknown Source)
at com.sun.java.swing.plaf.windows.WindowsTreeUI$WindowsTreeCellRenderer.<init>(Unknown Source)
at com.sun.java.swing.plaf.windows.WindowsTreeUI.createDefaultCellRenderer(Unknown Source)
at javax.swing.plaf.basic.BasicTreeUI.updateRenderer(Unknown Source)
at javax.swing.plaf.basic.BasicTreeUI.completeUIInstall(Unknown Source)
at javax.swing.plaf.basic.BasicTreeUI.installUI(Unknown Source)
at javax.swing.JComponent.setUI(Unknown Source)
at javax.swing.JTree.setUI(Unknown Source)
at javax.swing.JTree.updateUI(Unknown Source)
at com.servoy.extensions.beans.dbtreeview.SwingDBTree.updateUI(SwingDBTree.java:121)
at javax.swing.JTree.<init>(Unknown Source)
at javax.swing.JTree.<init>(Unknown Source)
at com.servoy.extensions.beans.dbtreeview.SwingDBTree.<init>(SwingDBTree.java:68)
at com.servoy.extensions.beans.dbtreeview.SwingDBTreeView.<init>(SwingDBTreeView.java:115)
at com.servoy.extensions.beans.dbtreeview.DBTreeView.getSwingDBTreeView(DBTreeView.java:94)
at com.servoy.extensions.beans.dbtreeview.DBTreeView.getBeanInstance(DBTreeView.java:72)
at com.servoy.eclipse.ui.util.ElementUtil.getPersistScriptClass(ElementUtil.java:364)
at com.servoy.eclipse.debug.script.TypeCreator$ElementsScopeCreator.createFormElementProperties(TypeCreator.java:2966)
at com.servoy.eclipse.debug.script.TypeCreator$ElementsScopeCreator.createType(TypeCreator.java:2938)
at com.servoy.eclipse.debug.script.TypeCreator.createDynamicType(TypeCreator.java:801)
at com.servoy.eclipse.debug.script.TypeCreator.createDynamicType(TypeCreator.java:793)
at com.servoy.eclipse.debug.script.TypeCreator.createType(TypeCreator.java:447)
at org.eclipse.dltk.javascript.typeinfo.TypeCache.getType(TypeCache.java:203)
at org.eclipse.dltk.javascript.typeinfo.TypeCache$TypeCacheResourceSet.resolve(TypeCache.java:333)
at org.eclipse.dltk.javascript.typeinfo.TypeUtil.resolve(TypeUtil.java:255)
at org.eclipse.dltk.javascript.typeinfo.model.impl.SimpleTypeImpl.eResolveProxy(SimpleTypeImpl.java:144)
at org.eclipse.dltk.javascript.typeinfo.model.impl.SimpleTypeImpl.getTarget(SimpleTypeImpl.java:79)
at org.eclipse.dltk.javascript.typeinfo.model.impl.SimpleTypeImpl.toRType(SimpleTypeImpl.java:127)
at org.eclipse.dltk.javascript.typeinfo.RTypes.create(RTypes.java:257)
at org.eclipse.dltk.internal.javascript.ti.TypeSystemImpl$1.getIRType(TypeSystemImpl.java:258)
at org.eclipse.dltk.internal.javascript.ti.TypeSystemImpl$1.getName(TypeSystemImpl.java:276)
at org.eclipse.dltk.internal.javascript.ti.TypeInferencerVisitor.isXML(TypeInferencerVisitor.java:193)
at org.eclipse.dltk.internal.javascript.ti.TypeInferencerVisitor.extractNamedChild(TypeInferencerVisitor.java:1232)
at org.eclipse.dltk.internal.javascript.ti.TypeInferencerVisitor.visitPropertyExpression(TypeInferencerVisitor.java:1222)
at org.eclipse.dltk.internal.javascript.validation.TypeInfoValidator$ValidationVisitor.visitPropertyExpression(TypeInfoValidator.java:1602)
at org.eclipse.dltk.internal.javascript.ti.TypeInferencerVisitor.visitPropertyExpression(TypeInferencerVisitor.java:1)
at org.eclipse.dltk.javascript.ast.ASTVisitor$31.handle(ASTVisitor.java:200)
at org.eclipse.dltk.javascript.ast.ASTVisitor.visit(ASTVisitor.java:298)
at org.eclipse.dltk.internal.javascript.ti.TypeInferencerVisitorBase.visit(TypeInferencerVisitorBase.java:119)
at org.eclipse.dltk.internal.javascript.validation.TypeInfoValidator$ValidationVisitor.visit(TypeInfoValidator.java:510)
at org.eclipse.dltk.internal.javascript.ti.TypeInferencerVisitor.visitPropertyExpression(TypeInferencerVisitor.java:1221)
at org.eclipse.dltk.internal.javascript.validation.TypeInfoValidator$ValidationVisitor.visitPropertyExpression(TypeInfoValidator.java:1602)
at org.eclipse.dltk.internal.javascript.ti.TypeInferencerVisitor.visitPropertyExpression(TypeInferencerVisitor.java:1)
at org.eclipse.dltk.javascript.ast.ASTVisitor$31.handle(ASTVisitor.java:200)
at org.eclipse.dltk.javascript.ast.ASTVisitor.visit(ASTVisitor.java:298)
at org.eclipse.dltk.internal.javascript.ti.TypeInferencerVisitorBase.visit(TypeInferencerVisitorBase.java:119)
at org.eclipse.dltk.internal.javascript.validation.TypeInfoValidator$ValidationVisitor.visit(TypeInfoValidator.java:510)
at org.eclipse.dltk.internal.javascript.validation.TypeInfoValidator$ValidationVisitor.visitCallExpression(TypeInfoValidator.java:817)
at org.eclipse.dltk.internal.javascript.ti.TypeInferencerVisitor.visitCallExpression(TypeInferencerVisitor.java:1)
at org.eclipse.dltk.javascript.ast.ASTVisitor$5.handle(ASTVisitor.java:65)
at org.eclipse.dltk.javascript.ast.ASTVisitor.visit(ASTVisitor.java:298)
at org.eclipse.dltk.internal.javascript.ti.TypeInferencerVisitorBase.visit(TypeInferencerVisitorBase.java:119)
at org.eclipse.dltk.internal.javascript.validation.TypeInfoValidator$ValidationVisitor.visit(TypeInfoValidator.java:510)
at org.eclipse.dltk.internal.javascript.ti.TypeInferencerVisitor.visitVoidExpression(TypeInferencerVisitor.java:1404)
at org.eclipse.dltk.internal.javascript.ti.TypeInferencerVisitor.visitVoidExpression(TypeInferencerVisitor.java:1)
at org.eclipse.dltk.javascript.ast.ASTVisitor$37.handle(ASTVisitor.java:230)
at org.eclipse.dltk.javascript.ast.ASTVisitor.visit(ASTVisitor.java:298)
at org.eclipse.dltk.internal.javascript.ti.TypeInferencerVisitorBase.visit(TypeInferencerVisitorBase.java:119)
at org.eclipse.dltk.internal.javascript.validation.TypeInfoValidator$ValidationVisitor.visit(TypeInfoValidator.java:510)
at org.eclipse.dltk.internal.javascript.ti.TypeInferencerVisitor.visitStatementBlock(TypeInferencerVisitor.java:1312)
at org.eclipse.dltk.internal.javascript.ti.TypeInferencerVisitor.visitStatementBlock(TypeInferencerVisitor.java:1)
at org.eclipse.dltk.javascript.ast.ASTVisitor$32.handle(ASTVisitor.java:205)
at org.eclipse.dltk.javascript.ast.ASTVisitor.visit(ASTVisitor.java:298)
at org.eclipse.dltk.internal.javascript.ti.TypeInferencerVisitorBase.visit(TypeInferencerVisitorBase.java:119)
at org.eclipse.dltk.internal.javascript.validation.TypeInfoValidator$ValidationVisitor.visit(TypeInfoValidator.java:510)
at org.eclipse.dltk.internal.javascript.ti.TypeInferencerVisitor.visitIfStatements(TypeInferencerVisitor.java:1040)
at org.eclipse.dltk.internal.javascript.validation.TypeInfoValidator$ValidationVisitor.visitIfStatement(TypeInfoValidator.java:2364)
at org.eclipse.dltk.internal.javascript.ti.TypeInferencerVisitor.visitIfStatement(TypeInferencerVisitor.java:1)
at org.eclipse.dltk.javascript.ast.ASTVisitor$19.handle(ASTVisitor.java:137)
at org.eclipse.dltk.javascript.ast.ASTVisitor.visit(ASTVisitor.java:298)
at org.eclipse.dltk.internal.javascript.ti.TypeInferencerVisitorBase.visit(TypeInferencerVisitorBase.java:119)
at org.eclipse.dltk.internal.javascript.validation.TypeInfoValidator$ValidationVisitor.visit(TypeInfoValidator.java:510)
at org.eclipse.dltk.internal.javascript.ti.TypeInferencerVisitor.visitStatementBlock(TypeInferencerVisitor.java:1312)
at org.eclipse.dltk.internal.javascript.ti.TypeInferencerVisitor.visitStatementBlock(TypeInferencerVisitor.java:1)
at org.eclipse.dltk.javascript.ast.ASTVisitor$32.handle(ASTVisitor.java:205)
at org.eclipse.dltk.javascript.ast.ASTVisitor.visit(ASTVisitor.java:298)
at org.eclipse.dltk.internal.javascript.ti.TypeInferencerVisitorBase.visit(TypeInferencerVisitorBase.java:119)
at org.eclipse.dltk.internal.javascript.validation.TypeInfoValidator$ValidationVisitor.visit(TypeInfoValidator.java:510)
at org.eclipse.dltk.internal.javascript.ti.TypeInferencerVisitor.visitFunctionBody(TypeInferencerVisitor.java:894)
at org.eclipse.dltk.internal.javascript.ti.TypeInferencerVisitor.visitFunctionStatement(TypeInferencerVisitor.java:852)
at org.eclipse.dltk.internal.javascript.validation.TypeInfoValidator$ValidationVisitor.visitFunctionStatement(TypeInfoValidator.java:672)
at org.eclipse.dltk.internal.javascript.ti.TypeInferencerVisitor.visitFunctionStatement(TypeInferencerVisitor.java:1)
at org.eclipse.dltk.javascript.ast.ASTVisitor$17.handle(ASTVisitor.java:127)
at org.eclipse.dltk.javascript.ast.ASTVisitor.visit(ASTVisitor.java:298)
at org.eclipse.dltk.internal.javascript.ti.TypeInferencerVisitorBase.visit(TypeInferencerVisitorBase.java:119)
at org.eclipse.dltk.internal.javascript.validation.TypeInfoValidator$ValidationVisitor.visit(TypeInfoValidator.java:510)
at org.eclipse.dltk.internal.javascript.ti.TypeInferencerVisitor.visitVoidExpression(TypeInferencerVisitor.java:1404)
at org.eclipse.dltk.internal.javascript.ti.TypeInferencerVisitor.visitVoidExpression(TypeInferencerVisitor.java:1)
at org.eclipse.dltk.javascript.ast.ASTVisitor$37.handle(ASTVisitor.java:230)
at org.eclipse.dltk.javascript.ast.ASTVisitor.visit(ASTVisitor.java:298)
at org.eclipse.dltk.internal.javascript.ti.TypeInferencerVisitorBase.visit(TypeInferencerVisitorBase.java:119)
at org.eclipse.dltk.internal.javascript.validation.TypeInfoValidator$ValidationVisitor.visit(TypeInfoValidator.java:510)
at org.eclipse.dltk.internal.javascript.ti.TypeInferencerVisitorBase.visit(TypeInferencerVisitorBase.java:1)
at org.eclipse.dltk.javascript.ast.ASTVisitor.visit(ASTVisitor.java:25)
at org.eclipse.dltk.internal.javascript.ti.TypeInferencerVisitor.visitScript(TypeInferencerVisitor.java:1296)
at org.eclipse.dltk.internal.javascript.ti.TypeInferencerVisitor.visitScript(TypeInferencerVisitor.java:1)
at org.eclipse.dltk.javascript.ast.ASTVisitor$14.handle(ASTVisitor.java:111)
at org.eclipse.dltk.javascript.ast.ASTVisitor.visit(ASTVisitor.java:298)
at org.eclipse.dltk.internal.javascript.ti.TypeInferencerVisitorBase.visit(TypeInferencerVisitorBase.java:119)
at org.eclipse.dltk.internal.javascript.validation.TypeInfoValidator$ValidationVisitor.visit(TypeInfoValidator.java:510)
at org.eclipse.dltk.internal.javascript.ti.TypeInferencer2.doInferencing(TypeInferencer2.java:104)
at org.eclipse.dltk.internal.javascript.validation.TypeInfoValidator.build(TypeInfoValidator.java:158)
at org.eclipse.dltk.internal.core.builder.StandardScriptBuilder.buildModule(StandardScriptBuilder.java:260)
at org.eclipse.dltk.internal.core.builder.StandardScriptBuilder.buildNatureModules(StandardScriptBuilder.java:200)
at org.eclipse.dltk.internal.core.builder.StandardScriptBuilder.build(StandardScriptBuilder.java:72)
at org.eclipse.dltk.internal.core.builder.ScriptBuilder.fullBuild(ScriptBuilder.java:449)
at org.eclipse.dltk.internal.core.builder.ScriptBuilder.build(ScriptBuilder.java:156)
at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:728)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:199)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:239)
at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:292)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:295)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:256)
at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:394)
at org.eclipse.core.internal.resources.Project$1.run(Project.java:618)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2344)
at org.eclipse.core.internal.resources.Project.internalBuild(Project.java:597)
at org.eclipse.core.internal.resources.Project.build(Project.java:114)
at com.servoy.eclipse.model.extensions.AbstractServoyModel.buildActiveProjects(AbstractServoyModel.java:313)
at com.servoy.eclipse.model.extensions.AbstractServoyModel.buildActiveProjects(AbstractServoyModel.java:288)
at com.servoy.eclipse.core.ServoyModel$7.run(ServoyModel.java:966)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Weird that’s something deep down in Swing itself that wants to its UIDefaults, i guess creating a specific icon that it then wants to load from the system, and somehow the filesystem interface is not initializing correctly
jcompagner:
Weird that’s something deep down in Swing itself that wants to its UIDefaults, i guess creating a specific icon that it then wants to load from the system, and somehow the filesystem interface is not initializing correctly
I suspect this issue has some common root with the leaking handles and the “out-of-memory” exceptions which we are getting, because after it I need to restart the Servoy Developer.
The build process today was quite slow for me. I had to switch the active solution several times and after that the build process became extremely slow. Attached is a file with a few stack dumps during that process.
your out of handles is a SWT related issue, this is more a Swing thing, but maybe deep down in the native layer they could have something to do with each other
But as long as you didn’t get the swt out of handles first and then the swing thing i don’t know if they are really related.
rossent:
The build process today was quite slow for me. I had to switch the active solution several times and after that the build process became extremely slow. Attached is a file with a few stack dumps during that process.
does this only happen when you switch a few times of the active solution?
Because what it does what i see in the stacktrace, will happen all the time when you change something of a form (and that form extends another form)
Did you change and save something of such a form and then it happens? And it doesn’t happen if you don’t switch a few times between active solutions?
rossent:
The build process today was quite slow for me. I had to switch the active solution several times and after that the build process became extremely slow. Attached is a file with a few stack dumps during that process.
does this only happen when you switch a few times of the active solution?
Because what it does what i see in the stacktrace, will happen all the time when you change something of a form (and that form extends another form)
Did you change and save something of such a form and then it happens? And it doesn’t happen if you don’t switch a few times between active solutions?
Now that I have restarted the Servoy Developer, I can see that it is slow even without switching the active solution.
but what i see there is a Refresh Action of the solex tree.
Do you changes file underneath the developer?
Normally a form or its elements almost don’t change except that you change what you are editing and then do a save… But that is a one time flush of 1 form and that should be it.
But what i think i see in your stack trace is a constant change of i think scripts (method or variables) of a form an then i guess loads of them.
jcompagner:
but what i see there is a Refresh Action of the solex tree.
Do you changes file underneath the developer?
Normally a form or its elements almost don’t change except that you change what you are editing and then do a save… But that is a one time flush of 1 form and that should be it.
But what i think i see in your stack trace is a constant change of i think scripts (method or variables) of a form an then i guess loads of them.
In a team environment this happens all the time - other developers make changes to the code, and when I update my workspace with the latest changes from the SVN repository, this happens “behind the Servoy Developer”'s back (we are not using the Eclipse SVN client). In additions, we have some media files which are being updated outside the Servoy Developer.
Is there anybody also having weird scrollbar behaviour in the webclient tableview?
Some of my tableview forms are behaving as expected (with scrollbar), while others just keep on showing page numbering instead.
I’ve been through al kinds of properties but I just can’t find any differences between the “scrollbarred” and the “page numbered” ones.
maarten:
Is there anybody also having weird scrollbar behaviour in the webclient tableview?
Some of my tableview forms are behaving as expected (with scrollbar), while others just keep on showing page numbering instead.
I’ve been through al kinds of properties but I just can’t find any differences between the “scrollbarred” and the “page numbered” ones.
maarten:
Is there anybody also having weird scrollbar behaviour in the webclient tableview?
Some of my tableview forms are behaving as expected (with scrollbar), while others just keep on showing page numbering instead.
I’ve been through al kinds of properties but I just can’t find any differences between the “scrollbarred” and the “page numbered” ones.
maarten:
Is there anybody also having weird scrollbar behaviour in the webclient tableview?
Some of my tableview forms are behaving as expected (with scrollbar), while others just keep on showing page numbering instead.
I’ve been through al kinds of properties but I just can’t find any differences between the “scrollbarred” and the “page numbered” ones.
jcompagner:
but what i see there is a Refresh Action of the solex tree.
Do you changes file underneath the developer?
Normally a form or its elements almost don’t change except that you change what you are editing and then do a save… But that is a one time flush of 1 form and that should be it.
But what i think i see in your stack trace is a constant change of i think scripts (method or variables) of a form an then i guess loads of them.
In a team environment this happens all the time - other developers make changes to the code, and when I update my workspace with the latest changes from the SVN repository, this happens “behind the Servoy Developer”'s back (we are not using the Eclipse SVN client). In additions, we have some media files which are being updated outside the Servoy Developer.
why are you not using the tooling that eclipse provides through plugins??
Now resources are constantly out of sync and complete refreshes are quite big operations.
We are also in a team development over many developers but we all use svn plugins and we almost never have to refresh our workspace…
