LabVIEW .NET event memory leak

[HJPhilippi]

Hi all,

we're using LabVIEW 8.6 together with some .NET assemblies I've written, making use of .NET events and callback VIs that transform the event data into LabVIEW internal events. When I monitor the memory use of our application with Perfmon, I find it constantly increasing.
After some research I came to the conclusion that the LabVIEW .NET event mechanism itself may be the problem, perhaps together with the .NET garbage collector: I suspect it not to "clean up" the orphaned event data references properly. Even closing them manually doesn't seem to help here (see example described below) - is it LabVIEW that still holds a handle to them so the .NET GC won't do its job?
Or am I doing something completely wrong?!?

The provided example shows that simply registering a .NET event handler in LabVIEW is enough to reproduce the described effect. If you run 'Main.vi' and record LabVIEW's memory use for some time ("Private Bytes" in Perfmon), you'll find it constantly increasing. The Visual Studio 2008 project of the used .NET example DLL is included, it's a most simple event generator class that fires an own event type containing some dummy data.

Well, as always in the miracolous "LabVIEW meets .NET" area, I've little hope to get valuable information from NI, not to speak of a solution for the problem... Nevertheless I keep trying, so I post the whole thing here to get some minor publicity. 😉

Best regards,
Hans

[aeastet]

Looking at you Main.vi you need to close your references.

 

[billko]

---

aeastet wrote:

Looking at you Main.vi you need to close your references.

 

---

Wa-wahhh...  😉

[HJPhilippi]

Well, nice try, but... how would closing 1 (and it is only one) reference help with constantly increasing memory occupation? Just do it like shown in your screenshot, start Perfmon, and see the effect is still the same.

And what if you needed the one and only 'TestEventProducer' reference inside the event loop? This is just a raw example with an empty main loop, in real world application you'd surely need it and therefore would definitely not close it.

Best regards,

Hans

P.S.: I think this is a problem beyond the "Are you sure to have fuel in the tank?" category...

[billko]

---

HJPhilippi wrote:

Well, nice try, but... how would closing 1 (and it is only one) reference help with constantly increasing memory occupation? Just do it like shown in your screenshot, start Perfmon, and see the effect is still the same.

And what if you needed the one and only 'TestEventProducer' reference inside the event loop? This is just a raw example with an empty main loop, in real world application you'd surely need it and therefore would definitely not close it.

Best regards,

Hans

P.S.: I think this is a problem beyond the "Are you sure to have fuel in the tank?" category...

---

This is a problem even if not THE problem.  If you have any programming experience, you know that every reference consumes the memory associated with it.  If you never give the resources back and keep opening new ones...

[aeastet]

With the VI's that you sent this is a problem if you do not close your reference. I would agree that maybe you have something else going on but in the example that you gave us to look at there is no memory leak on my computer that I can see. What exactly are you seeing on your computer because I am looking at the physical memory, kernel memory and commit charge and they are not getting bigger on my computer.

You are correct if you needed the reference inside you loop you would close the reference after it was used. If you leave a reference open and call it over and over this will cause a memory leak. With the VI's that you sent that is the only thing I see. 

[HJPhilippi]

---

billko wrote:

[...] If you have any programming experience, you know that every reference consumes the memory associated with it.  If you never give the resources back and keep opening new ones...

---

Yes, I have a little programming experience and I do know that resources are precious. However, the named resource ('TestEventProducer' reference) is opened only once with programm start, could be (re)used while the program/VI is running, and should be closed while the VI finishes.

Any other resource that actually is opened over and over again (not the case with 'TestEventProducer') should be closed immediately or even better managed in some sort of resource/reference pool to save the overhead of creating/releasing it. No doubt about that.

Cheers,

Hans

Message Edited by HJPhilippi on 10-02-2009 09:39 PM

[HJPhilippi]

First of all: I missed to say that I appreciate your comments. I really do!

---

@aeastet wrote:

With the VI's that you sent this is a problem if you do not close your reference. I would agree that maybe you have something else going on but in the example that you gave us to look at there is no memory leak on my computer that I can see. What exactly are you seeing on your computer because I am looking at the physical memory, kernel memory and commit charge and they are not getting bigger on my computer.

---

I'm recording the Private Bytes with Perfmon and that is -as far as I know- the actual amount of memory an application allocates. See eg. http://www.itwriting.com/dotnetmem.php

While I'm writing these lines, I'm recording it once again - a revised version of Main.vi with the reference closed immediately, as recommended. And this is the result I see after 10 mins:

---

@aeastet wrote:

You are correct if you needed the reference inside you loop you would close the reference after it was used. If you leave a reference open and call it over and over this will cause a memory leak. With the VI's that you sent that is the only thing I see. 

---

I don't see how and where the named (now closed) reference is called "over and over again". The only thing that's happening while the main loop stands completely still, waiting for the "Stop" button press, are the fast event callback VI runs in the background. This is where the memory goes.

BTW: In my example you can set the time, how quickly the events are fired. Set it fast, memory allocation rises fast. Set it slow, memory allocation rises slowly...

Hmmm?!?

Cheers,

Hans

[billko]

---

HJPhilippi wrote:

---

billko wrote:

[...] If you have any programming experience, you know that every reference consumes the memory associated with it.  If you never give the resources back and keep opening new ones...

---

Yes, I have a little programming experience and I do know that resources are precious. However, the named resource ('TestEventProducer' reference) is opened only once with programm start, could be (re)used while the program/VI is running, and should be closed while the VI finishes.

Any other resource that actually is opened over and over again (not the case with 'TestEventProducer') should be closed immediately or even better managed in some sort of resource/reference pool to save the overhead of creating/releasing it. No doubt about that.

Cheers,

Hans

Message Edited by HJPhilippi on 10-02-2009 09:39 PM

---

I was thinking more along the lines of: if it happened once, it could happen again. Since you did not mention the obvious issue there, maybe it's a common coding mistake for you.  It happens to all of us, where for some reason you missed something vital in your undsertanding of something.  Maybe it happens inside the loop.  It was my mistake that I couldn't open the VI and went with my gut feeling instead.

[aeastet]

How are you running this program. I am using the Mian.vi. Is this what you are doing?