Memory Leak in 6.0.2

[Justin Goeres]

Greetings. I am developing a moderately-sized (about 200 VIs) lab control
application in 6.0.2. It uses one main loop routine, and the 4 UI windows
pass control & indicator values into the main loop via reference. This is
under WinNT4.

When the program is launched, LabView uses about 27 MB of RAM. However, as
the program runs, the memory usage climbs about 50 KB per minute without
apparent bound. Furthermore, the longer the program has been running, the
longer it takes it to "clean up" when the program stops. After running for
about 16 hours, I've even seen it hang (Task Manager says "not responding")
on stopping.

Note that no matter how long the program runs, however, the VI profiler
NEVER shows the memory usage of any of the VIs getting out
of control. In
fact, the numbers almost never change.

I've already tried the following things to remedy the problem (based on the
KBase, and other posts here):
(1) I've removed all coercion dots where possible, and nowhere am I
coercing any arrays or clusters.
(2) All VI refs are appropriately closed when I'm done with them (most are
opened once and just reused until the program stops)
(3) Checked the "Deallocate memory ASAP" box in the Options.

So far, nothing has helped (or even changed) the situation, and I'm running
short on ideas. Can anyone offer me any insight into what might be
happening? Is this a common sort of problem that occurs when passing fairly
large amounts of data around by reference, and is there anything I can do
about it?

Thanks, in advance.

Justin Goeres
Indio Systems, Inc.
Pleasanton, CA

[Joe_Guo]

I had the similar problem with one of my project. However, the memory in my system did not increase (I used taskinfo2001 to check it). The OS was winNT Sever with SP4. The longer the program ran the longer for it to stop. never found a solution. One interesting thing I noticed that the taskinfo2001 showed at least 8 or 10 threads for labview. Majority of them were for user interface.

[mikeporter]

The most common causes for this type of problem are references that aren't closed. Note that even some control references can cause "leaks" like this. Also make sure your acquisition code isn't constantly reinitializing stuff without closing it.

Given the modest size of your application, I would be willing to look over your code if you send it. Please note that I am NOT a consultant looking for work--I already got a job I love. It's just that these problems are sometimes easier to spot whe looking at the code...

Mike...

"... after all, He's not a tame lion..."

[MichelC]

This sounds very much like a reference leak in your program and not like a memory leak in LabView (although you wrote that you already thought of that)

The fact that LabView 'cleans up' the memory (and probably stops responding at the same time) when you stop your program is characteristic of that kind of bug. In fact LabView is still running and is very busy at a system level (cpu >= 50%) closing a huge number of connections before exiting the vi that created them. This can take a while depending on their number (minutes or more). Check the amount of allocated memory with the task manager, and you will see that it (slowly) goes down and that LabView reponds again when it is back to normal (27Mb in your case).

- Make sure you terminate all kinds of reference =
Vis and files references BUT ALSO references to controls and indicators (property nodes).

- If you cannot easily find the unclosed reference, disable portions of your code until the problem goes away. Use the windows task manager and make sure that the number of handles is steady (a handle leak looks is a memory leak too).

Good luck.
Michel.

[Justin Goeres]

"MichelC" wrote...
> This sounds very much like a reference leak in your program and not
> like a memory leak in LabView (although you wrote that you already
> thought of that)
>
>
>
> - Make sure you terminate all kinds of reference = Vis and files
> references BUT ALSO references to controls and indicators (property
> nodes).

That was exactly the advice I needed. I never realized that I might need to
close references to controls/indicators, but it makes sense. I found a
couple places where a different refnum was being generated on every
iteration of a loop and reworked the code a bit, and now the problem seems
to be solved (fingers crossed).

In case anyone else is interested, the main source of my problem was a
Controls[]
property on a cluster refnum. Every time the loop accessed the
property, it generated a new set of refnums in the Controls[] array. Over
many iterations this led to (presumably) thousands & thousands of orphaned
refnums that were gradually draining my program's will to live.

Thanks for the help!
Regards,
Justin Goeres
Pleasanton, CA

[nate]

What did you do to fix this problem? I think that I am experiencing the same type of thing. Also, how do you close a reference to a property node for controls and indicators if there is not a reference wire going into or coming out of the node?

[Greg_McKaskle2]

> What did you do to fix this problem? I think that I am experiencing
> the same type of thing. Also, how do you close a reference to a
> property node for controls and indicators if there is not a reference
> wire going into or coming out of the node?

You do not need to close references to implicitly linked property nodes.
The references that need to be closed are the ones created with Open,
and the ones read as a property -- such as the Controls array of references.

Another litmus test is that if read mutiple times, do you get different
refnum values. If multiple reads return the same value, then it doesn't
actually have to be Closed. If each read returns another refnum, then
it is necessary to Close them explicitly if y
ou would like them closed
earlier than at VI completion.

Greg McKaskle