You May Not Know

Community Browser
Showing results for 
Search instead for 
Did you mean: 

Re: Be Careful What You Register

Example Gatekeeper

Thank you to Fabiola for reading through my post and doing her homework to prove that the original blog post was incorrect in many of its statements.


I won't have time until after NIWeek to properly edit the post so I am taking it down as to not spread incorrect information. I will try to put something back up when I have the chance to properly review all of the new information.


Matt J

Matt J
National Instruments | CLA

Thank you for posting this.
In my current application I'm using lots of user events and from time to time I was faced with 'Not enough memory' crashes. Now I know a place to look at.   

Is it possible to save 'Search for Unhandled' for an earlier version of LabVIEW or does it require LV2016 features?

Example Gatekeeper

I uploaded a 2013 version and attached it to the original post. It's just something that I threw together real quick that looks at all events fired and searches for User Event (unhandled) and will mark that VI. If the unhandled event isn't fired this VI wouldn't pick anything up so it would probably be best to create a VI Analyzer test to search for these cases.

Matt J
National Instruments | CLA
Member _Y_

Thank you, it is a very interesting information.


I believe, registered but not handling events could be considered as bad programming style. However, bad programming style is part of many projects which we see in our daily work.

_____________________________________ - Interface-based multiple inheritance for LabVIEW OOP
Active Participant


I tried to reproduce the issue of memory leak. I ran the VI you used for your example and used the "Profile Performance and Memory" tool as well as the "Profile Buffer Allocations" and neither one showed a memory leak. I also used the Task manager memory usage graph. 


Then I tried changing the VI to use a large array and used the same tools. It did not show a memory leak either. 


Then I brought the big guns, the Desktop Execution Trace Toolkit to monitor memory allocations and determine if there was a memory leak. And it shows how the memory is allocated when the event is fired immediately followed by the memory being freed up. This is consistent with what I was told by NI when I contacted them about this issue:


"As long as you wire the event registration refnum to an event structure in a loop, then unhandled events will be discarded and memory will not be consumed. You would only continually consume memory if you register for events and then never wire the resulting event reg. refnum to an Event structure.


If an the event reg. refnum is wired to an Event structure contain events which are not actually handled by the structure, the events are silently discarded and the Event structure goes back to sleep whenever they occur first in the event queue(s).


If the author has any evidence otherwise, it might be a bug that needs to be addressed, but by design, these events should be automatically discarded and not leak memory."


The only thing the Event inspector is doing is highlighting that the event was unhandled (and one can deduct the memory has been freed at that moment), it does not prove that there is a memory leak.




Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor
Example Gatekeeper

Interesting, I haven't looked at this in a bit but I thought there was a clear difference between what happened when the event was handled and when it was unhandled. If you can PM me the person you talked to at NI I can look into this again when I have some time and follow up with them.

Matt J
National Instruments | CLA

Hi Jacobson,


I'm the person Fab talked to, and I'm the co-designer of the Event structure.


I confirm that memory is only consumed there is no Event structure to wired to the event registration refnum at all, or the loop containing Event structure terminates and the Event structure can't no longer consume (and discard if unhandled) the events.  This is by design and not a bug, because LabVIEW has no way to know the event loop (or another one) won't resume at some later point.


There is no problem with not handling all registered events in an Event structure (other than stylistically), as long as the event registration refnum is wired to an Event structure which can execute.



Craig Smith