Memory leaks are the bane of any software application that must run continuously for long periods of time. The common causes -- building arrays or concatenating strings within loops -- are relatively easy to spot for most developers. However, leaks can sometimes creep into applications in seemingly harmless ways. Consider the following code snippet, developed by a local integrator, that was extracted from an instrument polling loop that runs in parallel to a main application.It looked innocuous enough to me... Sure, why not use a notifier to stop the loop when the main application is stopped? It seemed to run without problems under Windows. However, when it was downloaded to a PXI-RT target, it leaked like a screen door on a submarine. The fix was simple enough: put the Obtain Notifier outside of the loop and pass in the refnum through a tunnel. You would think that Obtain Notifier would simply return a pointer to the existing notifier, but apparently things work differently enough in RT to cause headaches. I haven't tried it yet, but I bet the same (mis)behavior is evident when obtaining refnums from other synchronization tools.
The moral of the story is a simple one you see over and over again: if a code element doesn't need to be in a loop, then don't put it there. Duh.
3 years ago
I think the shown code doesn't have a memory leak if you use 'force destroy' on the close queue primitive.
This will destroy all instances of the named queue.
Bob: Welcome to the LabVIEW blogosphere! I enjoyed your article and look forward to reading more from you, soon :) And, thanks for the link to Thinking in G. I'm happy to return the favor.
Ton: The "force destroy" is (probably) counter to how this code works, as it is using a named queue (which is typically created once and accessed many times as a sort of messaging global). If you force destroy, you could inadvertently delete a notification.
... and yes, Queues work just as notifiers do. My understanding is that semaphores/rendezvous work differently. The "Destroy" actually destroys the object. Notice the the naming on queues/notifiers it is "Obtain/Release" thus providing us a wee little clue as to the different behavior.
Great to have your blog up! I'll look forward to your articles and pass the info on.
I wish I could say anything intelligent about LabVIEW but instead I'll just say congrats on starting your blog!
Welcome to the LabVIEW blog family, Bob! I look forward to reading future insights.
However, I do have a concern about calling this situation a "memory leak." I posted on my blog about it.
Great to see your blog up and running Bob, and a nice article about memory lakes :)
You might want to add your blog to the LabVIEW blog list here: http://forums.lavag.org/blog.html
I have found a nightmare of a memory leak as well. If you continue to open DAQ tasks without clearing them, as in a while loop, and save to a shift register, the code leaks like a screen door.
Post a Comment