fbpx
× Visual Objects

Please use this forum to post questions about Visual Objects and Vulcan.NET

Memory leaks in the program

More
1 year 6 months ago #1 by Arne Ortlinghaus
Memory leaks in the program was created by Arne Ortlinghaus
When making self tests opening certain program items I saw that the programs always consume more memory - both, the VO-Win32 version and the X#-Dotnet version.
Using the Telerik Justtrace Memory profiler I could find the reasons.
The program allows to take a snapshot of all objects in memory, then a user can perform some actions like opening/closing a program item, and then a second snapshot can be taken.
The Memory profiler makes a comparison of all objects before and after and shows their object names in a list and the dependencies between them.

The culprit:
Objects were holding references on each other so that the Garbage Collector did not understand that all of them could be removed. Calling Destroy methods of one object in the destroy method of the other resolved this.

So in Dotnet are still valid the old VO garbage collector rules: the program should help to destroy objects where possible. What is impressive are the possibilities to analyze behavior of the programs from external.

Arne

Please Log in or Create an account to join the conversation.

More
1 year 6 months ago #2 by Chris Pyrgas
Replied by Chris Pyrgas on topic Memory leaks in the program
Hi Arne,

Thanks for sharing! Agreed, when an app is ported to .Net, an endless pool of possibilities opens up..

But I must add that in general, the .Net garbage collector is much more sophisticated than that of VO and it should remove objects that have references to each other, if they both go out of scope, provided of course there are no other active external references to them! So this makes me suspect, maybe calling the Destroy() method had the effect of NULLyfing some other external reference to those objects?

See the code below, it shows that 2 objects with references to each other can be collected. Although obviously in your app the scenario is way more complicated, so something else could have prevented the GC from collecting them.

Chris

FUNCTION Start() AS VOID
DoTest1()
DoTest2()
RETURN

FUNCTION DoTest1() AS VOID
LOCAL o1,o2 AS TestClass
o1 := TestClass{}
o2 := TestClass{}
o1:oRef := o2
o2:oRef := o1
RETURN
FUNCTION DoTest2() AS VOID
? "Press a key to invoke GC"
Console.ReadKey()
Gc.Collect()
? "GC invoked"
Console.ReadKey()
RETURN

CLASS TestClass
EXPORT oRef AS OBJECT
DESTRUCTOR()
? "Object collected"
END CLASS

XSharp Development Team
chris(at)xsharp.eu

Please Log in or Create an account to join the conversation.

More
1 year 6 months ago #3 by Arne Ortlinghaus
Replied by Arne Ortlinghaus on topic Memory leaks in the program
Hi Chris,
yes, it is true, that the GC in Dotnet is much better and resolves many of these relations. Surely it depends on the number of objects involved. In my case it was a chain of hundreds of objects connected together (Windows, servers, controls) - plus some additional drag+drop events programmed in C#. When removing the connections to these events all objects could be removed.

Please Log in or Create an account to join the conversation.