01-16-2014 04:44 AM
Hello all,
I am using the NotifyIcon library in an application with a tray icon and have found a possible memory leak related to changing the context menu and as a result, implemented some new functionality as a workaround (enabling & disabling the menu items).
In my application, the icon and menu are context sensitive to the state of the application - if the application loses it's TCP connection it will display a different icon and a different menu to when the connection is active. The way I do this in my application is as follows:
This VI is called when the state changes and the two wires that appear from the top of the image depend on the connection state of the application.
On some of the machines this software is installed to, they lose connection frequently so the icon/menu changes quite a lot - this causes a memory leak which was narrowed down to the 'Destroy Events and Re-register' call. Almost every time the icon changed, I was seeing a 0.4Mb rise in memory usage - which was causing some of the older PCs to collapse with out-of-memory errors in about a week. Strangely, using the Desktop Execution Trace Toolkit doesn't show any reference leaks while this is happening (Maybe it doesn't show .NET memory usage?).
I've attached a screenshot of the VI causing the memory leak
So my questions are:
1) What is causing this memory leak? Is it related to the static VI reference each time it re-registers the .NET Callback or something internal to .NET not being cleaned up perhaps? The other thing that I noticed is that in the 'Get All Menu Items' Sub-VI there are some unclosed .NET references:
2) Am I correct in that I need to call the 'Destroy Events and Re-register' VI if I want to have a dynamic menu? I guess perhaps as long as I know what all of the items in my menu will/could be, I can just register the events once and then modify the menu as a subset of those items.
To workaround the issue, instead I decided to grey out the menu items that don't apply in the current connection state (as all I'm doing is removing options that are invalid if the connection is lost). This isn't something that's wrapped in the NotifyIcon library so I thought I'd post it here in case anyone else finds it useful or if the library author wishes to include it in the library in a future release. The attached VI is compiled in LabVIEW 2011.
01-16-2014 05:52 AM
It seems you're not closing the .NET reference, that could cause a leak.
/Y
01-16-2014 08:15 AM
So I've been playing around with it a bit longer now and found a .NET reference leak in the new function that I provided. I have attached a fixed version (and it is in LabVIEW 2012, not 2011).
Looking around the 'Destroy Events and Re-register' VI there are also similar cases where .NET references are left open so I suspect that's the source of the growing memory usage.
I created a test executable and profiled the memory usage - using my workaround/new implementation the memory doesn't grow but using the old method of changing the menu items & re-registering the events causes significant memory leaks.
06-16-2016 07:45 AM
Just came across this, works great. Thanks for sharing.