How to interprete private bytes and memory leaks in a Progress/.Net application

lievencardoen

I have a question regarding memory leaks in our application.

First of all, it's a Progress ABL Application. Progress has added .NET support a couple of years ago, so it's really hard to know where memory leaks are coming from.

Progress is written in C, so you have an ABL layer, a unmanaged C layer and then .NET. And on top of that we are using Infragistics which is known to have a poor design (with memory leaks).

In Progress ABL we can track memory leaks by parsing log files. For the .NET side we use Ants Memory Profiler.

Now, we have gotten some memory leak bug fixes from Progress which help a lot in lowering the number of leaking objects.

Before the Progress bug fixes this was a list of leaking instances between two snapshots (Between the two snapshots I opened and closed 10 Custom Forms):

This is a list of leaking objects after Progress gave us a hotfix.

As you can see, the Progress Fixes solved some of the leaking objects. Leaking objects seem to have gone down with a factor 10 for the same test. However, if I look at the private bytes, before the Progress fix private bytes went up with 13.1 Mb. After the fix private bytes went up with 5.1 Mb. So not 10 times better as the objects.

My questions:

• After the fixes from Progress, there are still lots of objects staying alive. Is this normal? Shouldn't the Instance diff be zero for all objects? I can imagine that in a pure .NET Windows Forms application there might be some objects leaking, but not so many...
• If the objects go down with a factor 10, shouldn't private bytes also go down with a factor 10? And if not, what is consuming the 5.1 Mb private bytes? If I look at the Size diff (bytes) in Ants, I can't explain 5.1 Mb...
• Is there a way to profile memory leaks of unmanaged C applications?

Edit: OpenEdge Version 11.7.2 With a Hotfix solving three memory leak issues.

Russell D

Its hard to tell whats going on without more of an example. But here are some possible explanations

• If the objects go down with a factor 10, shouldn't private bytes also go down with a factor 10? And if not, what is consuming the 5.1 Mb private bytes? If I look at the Size diff (bytes) in Ants, I can't explain 5.1 Mb...

It depends on the size of the objects. For example if you have some objects:

(Object1) 5KB<br>(Object2) 3KB<br>(Object3) 2KB<br>(Object4) 450KB<br>(Object5) 1KB<br>(Object6) 9KB

and then if you remove objects 1, 2, and 6, which is 50% of the objects, you will only free 17 KB / 470 KB of space. With regards to the second part of the question, keep in mind that after removing some objects the data will became fragmented (there will be empty spaces between data) and those spaces could be counted as private bytes until .NET (or system) decides that defregmentation is needed, eg:

(Unallocated) 8KB<br>(Object3) 2KB<br>(Object4) 450KB<br>(Object5) 1KB<br>(Unallocated) 9KB<br>

regarding the question

• After the fixes from Progress, there are still lots of objects staying alive. Is this normal? Shouldn't the Instance diff be zero for all objects? I can imagine that in a pure .NET Windows Forms application there might be some objects leaking, but not so many...

It is hard to tell without a reproduction, but you can choose the type that you think should be already gone, and then go into "Instance categorizer" view:
​
​

Or if you want even more information you can go to the instance list and check what is preventing the chosen instance from being collected by the GC:
​


And finally no, you cannot profile unmanaged code.​

lievencardoen

Hey Russell D, I've asked Progress to explain the memory because it's probably unmanaged code... And that's a black box for me...

Thx for your explanation!