When does LabVIEW actually close object references?

[Majoree]

I wanted to find out how LabVIEW manages references to objects when a reference is distributed among more than one property node located within different structures. So I created a little test where I passed a reference into a for loop, modified the referenced object with a property node and closed the reference inside the loop, then ran the loop several times.

To my surprise, the VI ran without generating any errors. This doesn't make sense because once I closed the reference in the first iteration of the loop, when the second iteration occurred, the reference should have been invalid. Why did I not receive any errors?

This begs the question: what happens to references when they are passed to more than one
location within a VI? Does the reference need to be closed each time it is used, or only after it's been used for the last time?

Also, if the cluster "controls[]" property is used, do the references to all of the controls within the cluster have to be closed as well as the reference to the cluster itself?

This issue is very important to me because I am developing a very large VI that is meant to be run for days at a time, and at the moment, there is a memory leak in the program. I want to make sure that all of my references are closed before exiting any sub VIs and I'm not positive that simply closing the original reference passed into a sub VI is actually freeing up all of the memory. On the other hand, I'm afraid of closing references after each time they are used if they are going to be used again in the same VI before it finishes executing.

Does anybody have any insight on this matter?

[mikeporter]

The first question is what kind of reference did you pass into the loop in your test? If it's a reference to a front panel object, the behaviour you saw makes sense because those references don't need to be closed. When LV see an attempt to close such a reference it doesn't actully close anything--so it would make sense that you didn't get an error.

If you have a reference to an object that you have to explicitly open, or which comes from reading a property node (like the cluster controls[] property you mentioned) those do need to be explicitly closed.

You shouldn't be branching a reference that needs to be closed unless you can guarantee that the branch with the close on it will always finish last. Otherwise you will be invalidating a reference midw
ay through another process. SubVIs that use the same reference should either be daisy-chained together using a single reference, or each branch should open its own reference to the object.

Attached is a VI showing the effect that I think you were trying to demonstrate with your test.

Mike...

[wiebe@CARYA]

Hi,

Closing a reference to an object is valid (it doesn't produce an error) but
LV returns the same reference to the object. You can check this, just put a
probe on the reference wire. If you create references of a control on more
locations, every reference has the same value.

I guess LV doesn't close the reference, until the vi stops running (if you
restart the vi, the reference value is changed, continues run doesn't)!

Regards,

Wiebe.



"Majoree" wrote in message
news:506500000008000000834C0000-1023576873000@exchange.ni.com...
> I wanted to find out how LabVIEW manages references to objects when a
> reference is distributed among more than one property node located
> within different structures. So I created a little test where I
> passed a reference into a for loop, modified the referenced object
> with a property node and closed the reference inside the loop, then
> ran the loop several times.
>
> To my surprise, the VI ran without generating any errors. This
> doesn't make sense because once I closed the reference in the first
> iteration of the loop, when the second iteration occurred, the
> reference should have been invalid. Why did I not receive any errors?
>
> This begs the question: what happens to references when they are
> passed to more than one location within a VI? Does the reference need
> to be closed each time it is used, or only after it's been used for
> the last time?
>
> Also, if the cluster "controls[]" property is used, do the references
> to all of the controls within the cluster have to be closed as well as
> the reference to the cluster itself?
>
> This issue is very important to me because I am developing a very
> large VI that is meant to be run for days at a time, and at the
> moment, there is a memory leak in the program. I want to make sure
> that all of my references are closed before exiting any sub VIs and
> I'm not positive that simply closing the original reference passed
> into a sub VI is actually freeing up all of the memory. On the other
> hand, I'm afraid of closing references after each time they are used
> if they are going to be used again in the same VI before it finishes
> executing.
>
> Does anybody have any insight on this matter?

[Greg_McKaskle2]

> I wanted to find out how LabVIEW manages references...


Unfortunately, this depends a bit on which version of LV you are using.
It was changed for LV6.1 to ensure that front panel object references
wouldn't cause memory leaks, or more correctly, memory hoarding.

In LV6, the guideline is to close the reference the same number of times
you opened it or asked for its value. Opens are easy to spot. The
asking needs some more explanation. When you read the Controls[]
property for a cluster or the panel, you are asking the cluster or panel
to provide you with a bunch of references. In LV6, these were unique
references each time they were asked. If you do not want these
references to build up, your diagram needs to call Close on each of the
asked or opened references. Technically these aren't a leak since LV
still knows that they are allocated, and when the top-level VI finishes,
LV will clean them up. But in applications where the top-level VI run
continuously, then this hoarding of memory is the same as a true leak.
The size of the leak per reference is something like 20 to 40 bytes, so
not huge, but still a leak/hoard.

In LV6.1, the asking for references changed. They always return the
same reference, and it is a reference that cannot be closed by the user.
Trying to close it is not an error, but it will be ignored. This
means that the first time someone wants a reference to a control, a
reference is generated, and it will be the reference that is returned
everytime someone asks for the control reference. If your diagram calls
close already, no harm. If your diagram doesn't call close, no harm.
When this panel leaves memory and the reference no longer makes sense,
it will be torn down.

I need to make it clear that the new LV6.1 behavior is for control
references that are asked for. References returned from Open are the
same as before and should be Closed. So this doesn't affect VISA, File
I/O, and other types of references, it is specific to front panel
references.

In case it still isn't clear why the behavior changed, we started seeing
many diagrams written such that they leaked or hoarded memory. In
reality, spotting where a diagram asks for a reference is hard, and
everyone was missing them some of the time. So we changed the
implementation to be more forgiving. The downside is that LV now hoards
one reference and you can't tell it that you are totally finished with
it, but it is no longer a leak.

I hope this sheds some light. If you have additional questions, just ask.

Greg McKaskle

[Martin.D]

I have been trying to store some automation refs in a LV6.1 global, but when the vi is stopped then re-run the reference is no longer valid. Although on the probe the reference seems OK.

My VIs are going to be run in TestStand 2.1 and I plan to configure the instrument in one sequence then use it in another. I hope to keep various sub-refs (measurement objects etc) open between sequences, how can this be achived?

[Jim_Kring]

Greg,

I have tested and I don't see this new non-unique refnum generation feature in LV 6.1. I have attached the VI I used for testing.

-Jim

[John Lum]

Note: Greg subsequently pointed out on the Info-LabVIEW listserv that he jumped the gun a little bit on this point and the above comments do not actually apply to any currently released version of LabVIEW. Version 6.1 behaves in the same manner as 6.0, described above.

One might infer that an upcoming LabVIEW release will incorporate the memory management changes that Greg describes. These changes should be detailed in the release notes or other LabVIEW documentation.

John Lum
National Instruments