Memory leaks in the program

Public support forum for peer to peer support with related to the Visual Objects and Vulcan.NET products
Post Reply
User avatar
ArneOrtlinghaus
Posts: 412
Joined: Tue Nov 10, 2015 7:48 am
Location: Italy

Memory leaks in the program

Post by ArneOrtlinghaus »

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
User avatar
Chris
Posts: 4906
Joined: Thu Oct 08, 2015 7:48 am
Location: Greece

Memory leaks in the program

Post by Chris »

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
Chris Pyrgas

XSharp Development Team
chris(at)xsharp.eu
User avatar
ArneOrtlinghaus
Posts: 412
Joined: Tue Nov 10, 2015 7:48 am
Location: Italy

Memory leaks in the program

Post by ArneOrtlinghaus »

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.
Post Reply