memory release

[atrev]

We are currently trying to create our own mesh from vertices but when we add a mesh to the screen, even if we remove the mesh, either by code or in model explorer, no memory is released back to the operating system.

[nickz]

Hi atrev
What language are you using?
In .NET a quick suggestion is to avoid keeping references to any interfaces when they are no longer needed. One way is to set something like myIMesh = null; in C#
It is also possible that we have missed some scenario with reference counting, so there is a memory leak

Could you upload a simplest possible example with instructions how to reproduce?
Regards
Nick

[atrev]

We are using VB.net. We have also tried to manually removed simplexes and vertices between each creation.

I've uploaded the project example. Press the add and wait for it to complete, then use either the remove button, or delete from model viewer, and the memory goes up every time

[atrev]

Have you been able to reproduce the issue? If a fix is required, we need it quite soon

thanks

[nickz]

Sorry atrev
This will be addressed eventually. There really something urgent came up and we are busy with many things. You need a subscription to keep it on top of priorities. http://www.dynoinsight.com/phpBB3/viewt ... p?f=3&t=18
I assume you are using v4.3?
Nick

[atrev]

Is memory release a known issue? and yes we are using 4.3

[nickz]

Memory leaks are pretty common because the management is fiddly. They are often caused by the application and also by ourselves too (guilty)
You were first to report specifically about meshes. More recently somebody mentioned strange behaviour in meshes too but inconsistently. It can be something different.
v4.3 is easier
Nick

[nickz]

atrev,
I have debugged your sample. In this particular case it is caused by the fact that a reference to the removed section is not released (not set to Nothing) by the application

Briefly the situation is this: You have a large mesh section object in the model and ISection m_iSectMesh member of the form class which controls it. You delete all objects using iarr.RemoveAll() where IArray iarr is array of objects in the model. The problem is that the memory consumption is not going down after that.

This is because after everything has been removed from the model the application still has a reference to the removed section stored in the m_iSectMesh member of the class. This reference is not released until the form is destructed on closing the application. KernelCAD knows that you keep the reference so it does not delete the section from memory, otherwise any use of m_iSectMesh would cause a crash

Sections can exist without being added to any model. So KernelCAD assumes you need the section for something else when you call RemoveAll()
To fix the leak you just need to set m_iSectMesh to Nothign (null in C#, etc) when you do not need it anymore. I have checked this by adding m_iSectMesh = Nothing to Button2_Click() (delete button handler). With this after the delete button memory goes down almost to where it was before

So, briefly set to Nothing all references to any interfaces. All other interfaces are released automatically because they are acquired inside of scope of each method. So they are released by .NET when the method is exited. m_iSectMesh is different because is member of the class which stays alive during whole application life

KC does have leaks in some situations when internally some memory not reference-counted properly, but we believe they are small and happen relatively rarely.

Regards
Nick

[nickz]

Remember also that .NET garbage collection is not deterministic. The actual memory is released using an algorithm which from developer’s point of view is unpredictable. This means that the memory might not go down immediately and not by the exactly same amount.

In the example the Process.GetCurrentProcess().WorkingSet64 shows that some small amount of memory left unreleased. This might make sense in case some allocated small bits fit in already allocated memory pool and there is no reason in spending time to clean it up

In debugger I saw that the large mesh section was released very quickly at least as soon as the application returned to the idle state waiting for user input

Nick

[atrev]

We did more tests, and the problem didn't seem to occur again with the memory ever increasing, but around 20mb seems to be lost somewhere when we start using the control, as can be seen with the application, even when everything has been set to nothing, even when its been left for a while, and the garbage collection has been forced to collect. But as you say this may not be causing an issue, as long as its released when the application closes, and crashing on exit may also not be good for us