.net reference leaks

[Tesla1977]

Hey everyone,

we have a xml parser dll written in C# and call this from Labview.

This Sub-VI apparently produces 5 reference leaks, e.g. for "Step" which is read at the beginning, the list of parameters inside is cleared which should also release all objects within, then some new parameters are created and added to the list. After that the reference to "Step" is stored again for further use (reading the data within at a later time).

Why do I have those leaks? If I run this in a while loop I see LabVIEW using more and more memory.

[wiebe@CARYA · Accepted solution]

---

Tesla1977 wrote:

Why do I have those leaks? If I run this in a while loop I see LabVIEW using more and more memory.

---

Because you don't close the references you open.

Body needs to be closed.

Parameter needs to be closed.

Parameter in the for loop needs to be closed (after the add).

In short: close the references you open!

[Tesla1977]

Well, I think I found it. You posted while I was writing this 🙂

The yellow addition solved it.

My understanding before was, that by closing the reference to the item after adding it to the list would also make me unable to later retrieve the data from the list.

Apparently these are 2 different instances of a reference to the data.

Is my thinking correct?

[wiebe@CARYA]

---

@Tesla1977 wrote:

Well, I think I found it. You posted while I was writing this 🙂

The yellow addition solved it.

My understanding before was, that by closing the reference to the item after adding it to the list would also make me unable to later retrieve the data from the list.

Apparently these are 2 different instances of a reference to the data.

Is my thinking correct?

---

The reference is just referring to objects. Closing the reference closes, well, the reference. Not the object.

So you are correct. The parent has a reference to it's objects. When you get a reference to the objects, the reference count will be increased. Not closing the reference will leave the reference count on 1. This means the object it won't be removed from memory, even when the parent closes. The references themselves use memory as well. In short: close the references. All of them. 

You also need to close Body, and the outer loop Parameter. You open them before the for loop, you need to close them when done with them. These won't leak as much as the parameters in the for loop, but they will leak! A tiny bit over a longer time is still a lot!

[wiebe@CARYA]

BTW. I don't think you have to set Parameter and Body after the loop (please test first).

Parameter refers to the object in Body, so adding to it will add to the object. Setting it will simply set the exact reference to the exact same object. So the last two property nodes are redundant. Replace them with a close reference, and you should be good.

Same goes for the set VI at the end. The get vi at the start returns a reference. You modify the referred object. No need to set it. You might need to close it, although it depends on the implementation of the get\set.

[Tesla1977]

Yes, I did close the other references too and don't see any leaks in the Desktop Execution Toolkit anymore.

Now I have to change this in all of the approximately 5 million functions in the project.

Thx a lot.

[wiebe@CARYA]

---

@Tesla1977 wrote:

Now I have to change this in all of the approximately 5 million functions in the project.

Thx a lot.

---

At least you won't forget the lesson learned!

[tyk007]

One side note I can add - .NET CLR and GC doesn't use reference counting in the traditional sense to manage whether an object can be collected due to lack of references. This is a good starting reference https://docs.microsoft.com/en-us/dotnet/standard/garbage-collection/fundamentals. 

This thread also has some useful background information (here) but the general rule of thumb is, for any object that you have created a wire for, close the reference once you are done. The references will all get closed once the top level VI in the hierarchy goes idle but for some applications this can be a very long time away.