Servoy 6.0 alpha 4

[rossent]

Hi all,

We experienced today several crashes of Servoy Developer due to running out of memory. It appears that the the issues started after using for a short period of time the new Search for References (Ctrl+Shift+G) and/or JavaScript Search (Ctrl+H) options. The memory usage was constantly growing and nothing was being released back even after running manually the garbage collector (the option at the bottom of Servoy Developer). Perhaps there are some memory leaks related to this new functionality which should be taken care of.

Has anyone else experienced similar issues?

[jcompagner]

How much memory do you have assigned to Servoy developer?
In 6.0 you do need more memory then in 5.2 because there a loads more generated (The whole Type structure of all the types that are possible are generated when needed and thats quite a lot)

I am testing with a big solution, will do some more testing, but can you look what really triggers it for you?

[rossent]

How much memory do you have assigned to Servoy developer?
In 6.0 you do need more memory then in 5.2 because there a loads more generated (The whole Type structure of all the types that are possible are generated when needed and thats quite a lot)

I am testing with a big solution, will do some more testing, but can you look what really triggers it for you?

I personally use the default memory setting which comes in when installing Servoy (not sure how much is that, looks like 512MB)

I just had to restart the Servoy Developer again due to the same issue. Before the prior crash, I moved several from variables which are meant to be used as constants to a different form and I wanted to change all references to them. And 2 crashes before that I set all warnings to "Ignore" hoping that it could help a bit with the memory issue (there were still a bunch of JSDoc warning showing up though). This time all I really was doing is this:
1. Open a form script, selected a form variable and used the option Ctrl+Shift+G to find all references to it.
2. From the search result pane double-click on the found entries which opens the respective script file.
3. Make adjustments to the referenced code, save the file and close its tab so I am back to the first file.
4. Repeat the same with the next found references
5. Repeat the same with another form variable

I know that Search & Replace can do some of that as well and this is what I tried first when I got the first crash. So I decided to try this approach but after working on less than half a dozen files the Servoy Developer memory was back at about 490MB so I just closed it and reopen again... Kind of frustrating experience today with the crashes.... Up to now I did not notice such issues with Servoy 6 but I did not try to use these new options extensively before - hence the suspicion that they have to do something with it.

Some additional info: The solution which I am working on at the moment is quite big (~200000 LOC in the .js files) with about 40 modules in the whole workspace, the active solution referencing about 20 other modules.

[jcompagner]

i guess you guys have the same kind of large solution as TMA and yes then you do need a bit more memory at the moment
if you set it to 700MB or something like that does it still grow beyond that?

I will try to get the memory usage more down, but that is not really simple to do at the moment anymore, Especially if you have a large amount of modules.
It would be nice to somehow have another big solution or have the memory dump at the moment it crashes with out of memory you can do that by setting this as a jvm argument in the servoy.ini file:

-XX:+HeapDumpOnOutOfMemoryError

[rossent]

Unfortunately, sending you the complete solution will not be possible. I made the requested changes to the servoy.ini file and increased the memory to 768MB. Here is what the file looks like now:

Code: Select all

-startup
plugins/org.eclipse.equinox.launcher_1.1.0.v20100507.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.1.1.R36x_v20100810
--launcher.XXMaxPermSize
256m
-vmargs
-Xms40m
-Xmx768m
-XX:MaxPermSize=256M
-XX:+HeapDumpOnOutOfMemoryError


Will report back with any updates

[jcarlos]

Is there any UI option in Servoy Developer where we can increase memory after installation?

JC

[jcompagner]

no this has to be done in the servoy.ini file

[rossent]

Hi all,
We just discovered an issue: the form datasource property cannot be set on forms which extend a base form with no datasource selected.

To reproduce it, follow these steps:

1. Create a base form which is not based on a table - the datasource is not selected and shows up as -none- in the property editor.
2. Create a child form, and in the "New Form" wizard specify that it extends the base form, select a table for it and some data providers
3. Notice that when the form is created, the data providers are placed correctly on the new child form, however its datasource is set to -none- and the property editor does not allow a datasource to be selected!

Possible work-around is to either create the child form initially without specifying the "extendsFrom" and only after the form is created to select its base form from the property editor. A second approach is to manually modify the .frm file and fill in the datasource property

A case is created for this: 363895

This is a huge issue for us since most of our application forms have to extend some base form. Existing form are OK - the issue applies only to new forms created in Servoy 6. Hopefully a fix for this can make it in the next release.

[rossent]

i guess you guys have the same kind of large solution as TMA and yes then you do need a bit more memory at the moment
if you set it to 700MB or something like that does it still grow beyond that?

I will try to get the memory usage more down, but that is not really simple to do at the moment anymore, Especially if you have a large amount of modules.
It would be nice to somehow have another big solution or have the memory dump at the moment it crashes with out of memory you can do that by setting this as a jvm argument in the servoy.ini file:

-XX:+HeapDumpOnOutOfMemoryError

This is getting into a much bigger issue for us. Even after increasing the max memory which can be allocated to the Servoy Developer (I tried all the way to a 1GB), the issue is not resolved but rather postponed. After about an hour or so all the allocated memory is used up (even if the reference search is not being used), everything in the Developer starts crawling and we are forced to close and restart it in order to be able to continue to work. Definitely there are some memory leaks which should be plugged. I guess this can be reproduced even with a smaller solution, just allocate less memory for Servoy Developer in order to hit that mark sooner.

[jcompagner]

is the memory dump generated when you get an out of mem with the HeapDumpOnOutOfMemoryError setting?
Can you 7zip it and give servoy an url where i can download it?

[rossent]

is the memory dump generated when you get an out of mem with the HeapDumpOnOutOfMemoryError setting?
Can you 7zip it and give servoy an url where i can download it?

Thanks for looking into this issue.
Because this is interfering a lot with my work, I set up the max memory to over 1GB. Let me change it back to something smaller and get a dump with a reasonable for a download size for you.

[rossent]

Here are the details of the first error which pops up when we get the crash:

Code: Select all

Unhandled event loop exception
Java heap space


Then the generic Eclipse thing:

Code: Select all

Internal Error - an out of memory error has occurred...


At which point I select the option to exit the workbench. This generates the file java_pid2060.hprof in the Servoy Developer directory.
I will send you a private message where you can download the dump file from. I did reduce intentionally the max memory for Servoy Developer to get to the crash sooner, but the behavior was identical to what is happening when the setting is set to 1GB. Hopefully this helps.

[jcompagner]

Hi all,

On several occasions, we experienced an issue where after modifying the existing JSDoc comments for functions in order to resolve warnings in Servoy 6a4 and saving the changes, the JSDoc content is wiped off and replaced by the generic:

/**
* // TODO generated, please specify type and doc for the params
* @param {Object} paramName
* ...
*/

In those cases the Servoy Developer gets into some sort of an infinite loop where the @properties UUID constantly gets re-generated and the .js file is constantly being modified and saved (the toolbar "Save" buttons constantly "blink" from enabled to disabled state and the file "Undo" history is lost due to the numerous auto changes and saves). The Developer is not "frozen" and by manually making any change to the .js file "kills" the infinite loop but all changes made to the JSDoc comments are gone. In some cases, the auto-generated JSDoc overlaps with the edits which the programmers are doing in the moment resulting in invalid comment section altogether. We cannot reproduce this issue at will but multiple developers experience the same on different machines.

i have finally be able to reproduce this and fixed this for alpha 7

[martinh]

I have same kind of memory error in 5.2 as well.
Every 30 minutes my Servoy hangs and I have to quit the developer or I have to cancel it by the task manager.

I noticed that it is each time when Servoy prox. needs about 500MB of memory.
My servoy.ini file looks like this

Code: Select all

-startup
plugins/org.eclipse.equinox.launcher_1.0.201.R35x_v20090715.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.0.200.v20090519
--launcher.XXMaxPermSize
640m
-vmargs
-Xms40m
-Xmx1024m
-XX:MaxPermSize=512M

The moment I increase this -XX:MaxPermSize=512M setting to a higher value (for ex. 640M) then the following screen appears:

Capture.JPG (64.23 KiB) Viewed 18068 times

So it looks like somewhere there is a limitation in Servoy, but where and why?

[jcompagner]

why are you touching maxpermsize?
setting that to that value (640m) is way to much

150 or so should be more then enough maybe 200 but thats already a lot in my eyes

And if it hangs then it is most likely not really memory related but something else, just do a stack dump then on the admin pages.