Memory Leak - Events?

[Furbs]

I have a significant memory leak that showed up in the last few months. It gains 4.2 mB every 2 minutes. I've started to disable parts of my code to determine where it is. I've narrowed it down to a panel I added. It seems to be related to both the network and registering for the event of new data coming in. Currently, I get 0.3 Mbps every half second from the Real Time PXIe. That works out to be 4.5 mB every minute, which is suspiciously close to half my leak.

If you register for an user event, but then never make an event structure for it, it will still queue somewhere, right? I think this may be the issue and, therefore, its not associated with any VI in particular.  

I've ran the Profile Memory and Profile Buffer Allocations. Neither show a VI gaining in memory after 10 minutes. I ran the Event Inspector Window and saw no unhandled events, but since the registration and the intended event structure are not actually in the same VI, I'm not sure where I'd expect the unhandled event to be listed. All of these debugging tools are new to me so maybe I'm not using them fully. 

Is there a more inclusive way to dump the RAM to a file or something in a way that I could read what datatype everything is and see what's being repeated/left?

What are my options at this point? 

[altenbach]

---

@Furbs wrote:

I have a significant memory leak that showed up in the last few months. It gains 4.2 mB every 2 minutes.? 

---

4-5 millibytes seems very (very!) little. 😄

What do you do with the received data? I don't understand what you are doing with events. Can you show us some simplified code?

[rolfk]

The DETT (Desktop Execution Trace Toolkit) is a very helpful tool for this!

[Furbs]

haha, I meant 4.2 MB 😛

The event structure is mainly to update the screen with new data. My version is different from my predecessor in that he statically links all the data, I get all controls from the screen, filter for Type Defs, and then write the necessary data via FOR loop. I recently have been trying to make it work with setpoints so it has time to write the data to the real-time controller before updating the screen again, hence the Freeze array, key focus, indicator switches. Then, if the data is good, aka Found?, in the Single Sample Data (SS Data), it writes to the screen. Otherwise it changes to control to yellow background and disabled to indicate the data is bad. SS Data consists of a variant array. 

Originally, I did have an event registration I wasn't using at all, but after removing that, I still have the issue. 

[Furbs]

rolfk,

Could you elaborate on how this helps track memory usage? This tool is like Windows Resource Monitor, right? Logs everything that happens. I'm not sure I'd recognize anything suspicious. Is there a way to pair trace events to see universally unhandled user events?

[Furbs]

Oh thats cool! It just straight up tells you all the things you forgot to close when you stop the program. Even found a few items I didn't know needed closing/ unregister. However, forgetting to unregister for the event isn't causing the leak. Is there something in here that might tell me when an event registry was never used or a when a queue grows to a certain size?

[Kyle97330]

If you think that a "Register for events" is causing your issues, there's a fairly easy way to check and that's to add in a call to "Unregister for events"  on every single registration and see if that drops your memory usage a lot.  Even if doing this removes some data you do need, it will help isolate the cause.  You could maybe code it up so it unregisters only after ~15 minutes or so, making it much easier to see a big drop in RAM when it happens.

Something else to check for is nodes that might look like they're not adding memory, but actually are.  For instance, I see you're passing around references to controls into subVIs.  That by itself is harmless, but if you call something that gets the "OwningVI" reference on them, that adds a reference in memory that needs to be closed.  There could be other things going on in your subVIs there that just happen to coincide with your event structure use.  If there's ever a reference wire that you're not sure if it needs to be closed, one way to check is to probe the wire and view the reference as a hex address.  If the address changes each time you get the reference, it probably does need to be closed each time and if it's the same each time then it probably doesn't.

If none of that helps, then I think we need more information.  Can you post the actual VIs, backsaved to 2019 or so?  If not, could you at least post more screenshots of related items, such as:

• Dropdown showing all events handled by the event structure
• All locations where you call Register for Events
• The tooltip help for the wire coming out of Register for Events
• The contents of the subVIs called in the event case(s) that seem to cause memory increases

[Furbs]

Is there not a way to see the memory in some kind of raw form? I know it will mostly be nonsense to me but it will be 3 GB of repeating nonsense that should give me an idea if its a 

I put a 15 minute timer in the structure so it will end itself after growing some. I also changed the beginning to create all the registrations before the structure and dynamically unregister after the structure. After 15 minutes, the RAM did not suddenly decrease and it is still climbing. I now have no unregistered events, most are unregistered immediately after the structure now instead of waiting for a Destroy step. 

This still leads me to believe that there's an user event that isn't being handled at all. I'm going to leave the application running in development mode over night with Execution Trace on, but only looking for memory allocations over 100 MB. By morning, something should be making that list unless its just 10000 copies with no single ownership. 

[Kyle97330]

The terminology in your post leaves me a bit unsure what you're doing in your code.  Are you using "Unregister for events", "Destroy user event", or both?

(It would still be better if you could post VI files or at least a lot more screenshots...)

As for memory probing, the only form of LabVIEW memory probing I know of is Heap Peek:

https://labviewwiki.org/wiki/Heap_Peek

However I don't think that Heap Peek will help in your cases as its mostly meant for examining VI files in memory, you wouldn't be able to use it to view the contents of expanding RAM during runtime.

[Furbs · Accepted solution]

Sorry, I am Unregistering. We have VIs called Initialize and Destroy that are responsible for any creation/deletion necessary so I use those terms generically. 

I put in the 15 minute exit timer and it didn't even stop the issue, let alone reduce the RAM which makes me doubt any of the attached screenshots are relevant, but please let me know if you see anything suspicious. Not included is the Get SS Data, which just loops through the SS Data array, extracting the relevant variant attributes. As far as ALL the events, we have a plethora throughout the project but those are created by a library shared with other projects that do not have this leak. 

As far as the overnight test, nothing came into Trace that was over 100 MB. I guess the next option is to run it again but then take the log and write a program to pull out if a certain log event is happening more and more often. I'm not sure what I could look for to be honest.