[Progress Communities] [Progress OpenEdge ABL] Forum Post: RE: Investigating memory leaks - ABL memory profiler?

[jquerijero]

[quote user="Lieven De Foor"] Hi Laura, Yes, we are using Infragistics controls, and yes we've figured that these might be the main cause of issues. We're using Infragistics controls and UltraToolbarsManager extensively and reading articles like this one isn't really helping our mood: subjectively.blogspot.com/.../importance-of-recycling-memory.html By unstable I mean session crash in certain cases, possibly by cleaning up too rigorously... or by just hitting a bug in Infragistics Reading this KB article, am I right to conclude that references on both sides of the bridge can keep objects alive, and that cleaning up on either side can make the object available for garbage collection, assuming no references are kept on the other side? I've seen the occasional error where the .NET side expected something to be still there on the ABL side after a DELETE OBJECT, but can't readily reproduce so I can't provide the error number... If there are still references on the .NET side that we can't reach (bugs in Infragistics?), then we will never be able to have the objects properly deleted... I've taken the example of Progress KB - UltraToolbarsManager Memory Leak and ran that through the ANTS memory profiler, which clearly shows objects (not only Infragistics) staying around, while the destructor gets run on the ABL side. Is there any update on this bug (PSC00311825)? Creating the same in c# however, and having the GC run spontaneously, does not show these left-overs. Is this hinting to an OpenEdge bug instead of an Infragistics bug? We will experiment with explicitly calling the GC. Thanks [/quote] The result of PSC00311825 was the addition of THIS-OBJECT:ComponentsCollection:ADD(THIS-OBJECT:components) to the PDSOE form template after the InitializeComponent(). Based on our testing using JetBrains, it did help some to reclaim leaked memory, but it did not remove all the memory leaks, for example, System.String references were still not being cleaned up correctly, which for UltraToolbarManager control could be significant. We are now testing 11.7.3, and the memory leak issue is showing up again.

Continue reading...