Memory Leak - Events?

[Furbs]

So I just closed the project in LabVIEW but I didn't exit LabVIEW, it went to the Open Project screen like it usually does. The RAM is still sitting at almost 2 GiB. I think this means I have an actual NI problem, outside of my control, right? If LabVIEW doesn't event recognize the RAM to garbage collect it after it closes the project... Something bigger must be wrong?

[Kyle97330]

I don't see anything suspicious just in those screenshots.  Hard to be sure from just screenshots of course.

When you exit and go back to the Open Project screen if you have memory still in use, it could be a NI thing yes, but it could also be an ActiveX or DLL thing.  If you have any code using third-party ActiveX or DLLs, any memory they allocate but don't free will also get trapped until LabVIEW fully exits.  Any chance you have some of that buried in your code?

[Yamaeda]

---

@Furbs wrote:

So I just closed the project in LabVIEW but I didn't exit LabVIEW, it went to the Open Project screen like it usually does. The RAM is still sitting at almost 2 GiB. I think this means I have an actual NI problem, outside of my control, right? If LabVIEW doesn't event recognize the RAM to garbage collect it after it closes the project... Something bigger must be wrong?

---

LV is deliberately slow to return memory to the system/Windows. It's very slow and expensive to request new/more memory from the system for a process so LV hangs on to what it has for a long time in case it needs it.

[Intaris]

Not sure I follow 100% what you're doing.

When dealing with events we have:

The event itself (the thing we use to send events)

The Event registration refnum (After we register for that event, this can be dynamic (Register for Events node) or static (Event structure)

When quitting the VI, we need to destroy both the Event and the event registration refnum. Just unregistering for events will stop accumulating events in the event registration refnum, but will not clear the current contents.

We also need to remember to destroy the actual event. Interesting note: We can destroy the event BEFORE handling events which were registered from it. We can create event, register for event, fire event, destroy event, then handle the event registration refnum.  The event itself has a lifetime independent of the event registration refnum.

[Furbs]

That is interesting. 

It turned out that I was registering for an event that occurred every half second, but never utilizing it. Still baffled that with the memory tools NI does offer, it doesn't catch this kind of leak, I assume it would be decently common. I'm putting together some classes with inheritance. I tried to build in an option to use an additional subpanel but if the user didn't tie anything to it, it wouldn't call the Run of that subpanel. However, the Initialize was always called, so the registration was already built-in. This was code I wrote months ago but until recently, I had never NOT used the subpanel option. 

Thank you all for your help! I've learned more about events and our codebase uses them heavily so it will all be great information moving forward.

[Intaris]

So to be clear, you're triggering user events which have been registered for but which have never been assigned an event structure to handle.

Yes,t hat's user (programmer) error. That's not something LabVIEW can fix itself.

You're registering for something you've told LabVIEW you want to register for. It's your responsibility to either destroy the registration refnum (clearing your memory leak) or pass the registration refnum off to an event structure (which will also fix the problem since LabVIEW 2013, even if you don't define a specific handler for the event). LabVIEW appears to be doing what you're telling it to. It's not a leak, it's a valid way or collating events to be handled later. It's only a leak because you've forgotten to clear the memory by one of the two afore-mentioned ways.

As of 18.03.2024, LabVIEW has no capability to differentiate between the code you write and the code you WANTED to write. But who knows what the future brings?