LabVIEW .NET event memory leak

[HJPhilippi]

---

@billko wrote:

[...]It happens to all of us, where for some reason you missed something vital in your undsertanding of something.

---

Absolutely. Daily.

But let all the mistakes we make aside for a moment: Here, in this example, you have the complete code at your hands. The .NET DLL does nothing else but fire recurring events with some dummy payload and a -most simple- LabVIEW application does pretty much nothing. It stands still(!) in an event loop and executes VI callbacks in the background that do nothing. And the references are (now) all closed, everywhere.

Still the private bytes value is rising. Why?

Greetings,

Hans

[HJPhilippi]

---

@aeastet wrote:

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

---

Yes, open Main.vi and run once (should have disabled the run continously button).

And again: the ZIP contains all I have and use, too. Nothing else (LabVIEW, .NET) runing on my machine. It's a stripped down demo to examine this memory issue

[aeastet]

I have never used this memory manager before. I down loaded it and would like to set it up the same way you do so that I can see the problem.

[HJPhilippi]

---

@aeastet wrote:

I have never used this memory manager before. I down loaded it and would like to set it up the same way you do so that I can see the problem.

---

What did you download? I'm using Microsofts perfmon.exe that is part of Windows itself (located in the "system32" directory) and simply starts a snap-in for the Microsoft Management Console (namely perfmon.msc).

It's the only way to get trustworthy memory information. I can give you some more info on that tomorrow - right now it's late in Germany (10:36pm) and my family claims it's quitting time...

Cheers,

Hans

[aeastet]

I added the close ref to your code and ran it for 10 min. I did not see the memory go up. Here is what I did

I am going home for the weekend. I hope this helps.

[Imagineer]

Alright Philippi aka Hans.....I was able to reproduce the problem you reported. Am a novice in .Net  so require your help in verifying the location that I suspect to be the root cause......

<First - Information> 

Since DLL have to be re-entrant, they have their own instances created at runtime and their image becomes part of the calling process ...in your case....LabVIEW-Event-Handling.dll becomes part of LabVIEW.exe .....So when you see that the memory footprint of LabVIEW.exe increasing ...it could also be due to the DLL...and I dont think .Net's garbage collector plays any role here.......nor can NI's LabVIEW.

<Secondly - Root cause location> 

I suspect C# coding for the DLL. In TestEventProducer.cs you have two things:

1] 

           public class TestEventArgs : EventArgs

           {

                      public readonly byte[] SomeEventData = new byte[1024]; ---> This goes in Heap

                      public readonly int EventCount;

                      public TestEventArgs(int EventCount) {

                      this.EventCount = EventCount;

                      }

           }

2]

           private void EventTimer_Elapsed(object sender, ElapsedEventArgs e) {

           if (OnNextEvent != null) OnNextEvent(this, new TestEventArgs(++_EventCount));

           }

Here everytime OnNextEvent is invoked, a new instance of TestEventArgs is created in (heap) memory which is never dereferenced anywhere in the code. My understanding is that, if an instance of an object is created in heap, it needs to be explicitly dereference maybe by using delete [This holds valid in case of C++ ]. I dont think .Net's garbage collector will play it's role here. So with every new instance you have 1024bytes for SomeEventData hence the sizeable increase in memory which is easily seen in the TaskMonitor / Perfmon.

To confirm this as the root cause, Could you recompile the DLL by commenting the readonly byte array - SomeEventData. This will mean that you will still have memory leak but the size will be insignificant to notice over the duration mentioned.

Awaiting your confirmation.

Regards,

Tirthankar De

Message Edited by Imagineer on 10-02-2009 06:33 PM

Message Edited by Imagineer on 10-02-2009 06:34 PM

[HJPhilippi]

Hi Tirthankar De,

thank you very much for spending so much time and analyzing the project in detail!

---

Imagineer wrote:

[...] My understanding is that, if an instance of an objecs t is created in heap, it needs to be explicitly dereference maybe by using delete [This holds valid in case of C++ ].

---

You name it: this is correct in C/C++ but it isn't in .NET. The Microsoft .NET Framework takes (as long as you stay in the so-called "managed" area = not use unsafe pointers or DLL methods etc.) complete care of memory management. And that is what the .NET GC (Garbage Collector) is for. It does the whole reference counting for you and supervises, if an object on the heap is used or unused and removes it from memory, when the time has come (in a non deterministic manner).

See http://msdn.microsoft.com/en-us/library/0xy59wtx.aspx for more info on GC.

Taking this to my example: The .NET Runtime sees, if an instance of the TestEventArgs class is still used (referenced) or not and when it can be released and the memory it takes can become available again. This includes the byte array or any other data inside the class. In other words: you definitely do not have to do any memory management yourself in pure managed .NET applications.

The sole theory proves right as soon as you write a C# client for the DLL that works exactly like the LabVIEW Main.vi: Register a callback function that does pretty nothing, just receive the event calls. In this case, you'll find the private bytes of your .NET app (without LabVIEW) rise a liitle - but then drop down again after some time, rise again and drop down and so forth. You see the GC at work! After all, the memory use stays the same over time - without any manual memory management.

---

@Imagineer wrote:

To confirm this as the root cause, Could you recompile the DLL by commenting the readonly byte array - SomeEventData. This will mean that you will still have memory leak but the size will be insignificant to notice over the duration mentioned.

---

See above. Sure, if I commented this out, the effect would be less significant but the problem stays the same. And then, if I actually need the byte array data in my LabVIEW app...?!? That's the problem we have.

To cut a long story short: I know (from NI developers themselves) that the LabVIEW/.NET interface is not pure gold... They had some massive problems and did various fixes over the last years/versions. Some of them related to bugs I've reported - like a former disability with generic type names longer than 256 characters!

Back to our problem, I suspect LabVIEW to keep an unused/orphaned handle on every event argument instance = TestEventArgs even after the event handler VI has finished. And this keeps the .NET GC from releasing it. That's all.

But it's unconfirmed from NI and it's hard to get contact to the .NET working group as usual.

Cheers,

Hans

[HJPhilippi]

---

aeastet wrote:

I added the close ref to your code and ran it for 10 min. I did not see the memory go up. Here is what I did

I am going home for the weekend. I hope this helps.

---

When I do it the memory consuming effect stays the same...

Thanks anyway,

Hans

[Norbert_B]

Hans,

the issue is already reported at NI (#151665) and will be fixed in a future version of LV.

hope this helps,

Norbert

[Edit]: See this post as it refers to the same topic.

Message Edited by Norbert B on 10-05-2009 08:52 AM

[HJPhilippi]

---

Norbert B wrote

the issue is already reported at NI (#151665) and will be fixed in a future version of LV.

---

Hi Norbert,

at least I'm glad that it's not me "seeing ghosts" and there is a chance that the issue will be fixed some day. Many thanks for the feedback.

---

[Edit]: See this post as it refers to the same topic.

---

Well, I searched the forums for ".NET memory leak" before posting but did not find this thread. Weird...

Thanks agan,

Hans