LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Reference leaks

Solved!
Go to solution

Hi folks - I stubbed my toe by not closing references.  As I ran the app over & over, it would get more & more sluggish, until it started doing weird bad stuff.  Doop! So after I got smart enough to use the "Remove VI" method for the sub-paneled VI's upon ending the app, life got easier.  I'm trying to use Windows Task Manager to sniff out any more leaks, but it has very coarse granularity, not satisfactory.  I'm thinking I still see some sluggishness creeping in, though not near as bad.  I looked at

 

https://www.ni.com/en-us/support/documentation/supplemental/13/closing-references-in-labview.html

 

But I'm not sure I see anything really applicable.  Sure, I've got a bazillion control references floating around, but the document says "Although you should usually close references when you no longer need them, you can leave implicit references and references returned in the reference out terminal of unwired property and invoke nodes open, shown below, because a Close Reference function does not actually close these references or remove the target objects from memory.".

 

I'm wondering if you folks who fight these battles with large apps have any tricks up your sleeve to sniff this leak business out.  The "Profiler" comes to mind, but as I understand it, it will show me what's happening during a run, but not

Hi folks - I stubbed my toe by not closing references.  As I ran the app over & over, it would get more & more sluggish, until it started doing weird bad stuff.  Doop! So after I got smart enough to use the "Remove VI" method for the sub-paneled VI's upon ending the app, life got easier.  I'm trying to use Windows Task Manager to sniff out any more leaks, but it has very coarse granularity, not satisfactory.  I'm thinking I still see some sluggishness creeping in, though not near as bad.  I looked at

 

https://www.ni.com/en-us/support/documentation/supplemental/13/closing-references-in-labview.html

 

But I'm not sure I see anything really applicable.  Sure, I've got a bazillion control references floating around, but the document says "Although you should usually close references when you no longer need them, you can leave implicit references and references returned in the reference out terminal of unwired property and invoke nodes open, shown below, because a Close Reference function does not actually close these references or remove the target objects from memory.".

 

I'm wondering if you folks who fight these battles with large apps have any tricks up your sleeve to sniff this leak business out.  The "Profiler" comes to mind, but as I understand it, it shows me what's happening during a run, but not from run to subsequent run, references accumulating, etc., references accumulating, etc.  Any guidance you can give me? Nuch thanks, paul

0 Kudos
Message 1 of 8
(3,411 Views)
Solution
Accepted by topic author PaulOfElora

Use the Desktop Execution Trace Toolkit.  It can tell you all kinds of information, including reference leaks.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 2 of 8
(3,396 Views)
Solution
Accepted by topic author PaulOfElora

A little trick I have learned:

 

If you put a probe on a reference, most of the time it will give you either a hex code or an integer code, i.e. the memory address of the reference.

 

If you probe a reference that's in a loop (or in a subVI that's in a loop), if you get the same reference address out each time, you don't need to close it, but if you get a different reference address out each time, then you do.

 

If there's something you want to check but it's un-probe-able, you can check it programatically by using the "type cast" node to convert it to a U32 (or possibly U64, if you're using 64 bit), then use a feedback node to check it against the previous instance, and a "first call" node to not trigger on the first instance, and you can get a Boolean yes or no on whether a reference needs closing.

 

You can also check out the video "An End to Brainless LabVIEW Programming" which has a section that I've linked to directly that talks about reference closing, and it's by Darren Nattinger aka DNatt, who works for NI.

Message 3 of 8
(3,382 Views)

Thanks, crossrulz, I'll try it - paul

0 Kudos
Message 4 of 8
(3,371 Views)

Thanks Kyle - never would have thought of that - paul

0 Kudos
Message 5 of 8
(3,365 Views)

Whoa Dudes! The Good News: the Desktop Execution Trace works like a charm! And I'm learning all sorts of what goes on Under The Hood. The Bad News: I've got a lot of work to do to fix stuff.  Thanks much for the tip!

0 Kudos
Message 6 of 8
(3,288 Views)

@Kyle97330 wrote:

 

If you probe a reference that's in a loop (or in a subVI that's in a loop), if you get the same reference address out each time, you don't need to close it, but if you get a different reference address out each time, then you do.

While this is true, it won't hurt either to connect the refnum to a Close Reference node. Personally I find it much simpler to just use a Close Reference anyhow than trying to remember if I need to use one or not. For refnums that can't be closed, the Close Reference node is simply a No Operation.

 

If there's something you want to check but it's un-probe-able, you can check it programatically by using the "type cast" node to convert it to a U32 (or possibly U64, if you're using 64 bit), then use a feedback node to check it against the previous instance, and a "first call" node to not trigger on the first instance, and you can get a Boolean yes or no on whether a reference needs closing.


LabVIEW refnums are NOT pointers! Irrespective if you work in 32-bit or 64-bit they always are 32-bit values so far. 

Rolf Kalbermatter
My Blog
0 Kudos
Message 7 of 8
(3,282 Views)

@rolfk wrote:

@Kyle97330 wrote:

 

If you probe a reference that's in a loop (or in a subVI that's in a loop), if you get the same reference address out each time, you don't need to close it, but if you get a different reference address out each time, then you do.

While this is true, it won't hurt either to connect the refnum to a Close Reference node. Personally I find it much simpler to just use a Close Reference anyhow than trying to remember if I need to use one or not. For refnums that can't be closed, the Close Reference node is simply a No Operation.


This sounds simple but in some cases where you need to persist a reference through dozens of subVIs, or if you've embedded it in a cluster or class wire, and then close it at the very end of its usable lifetime, it can be difficult to know where that "end" is for certain.  If you do this check, you can find out earlier if you need to bother or if you can just let it go away naturally.

 


@rolfk wrote:

@Kyle97330 wrote:

If there's something you want to check but it's un-probe-able, you can check it programatically by using the "type cast" node to convert it to a U32 (or possibly U64, if you're using 64 bit), then use a feedback node to check it against the previous instance, and a "first call" node to not trigger on the first instance, and you can get a Boolean yes or no on whether a reference needs closing.

LabVIEW refnums are NOT pointers! Irrespective if you work in 32-bit or 64-bit they always are 32-bit values so far. 


This one was on me as a guess that I guess turned out wrong.  I never use 64-bit LabVIEW so I was just hedging against being corrected for not accounting for it.

0 Kudos
Message 8 of 8
(3,261 Views)