looking for memory leak in labview 6.02

[ciossek]

dear all,
my labview program needs an increasing amount of memory when running (at the time about 12k/s) which leads to swapping memory on my hdd.
i have found out that calling cluster references like Controls[] or decos[] leads to this kind of memory leak and made a work around for that (simply calling it only once at runtime) but there are more memory leak(s)which i cannot find. The bugs that i have found searching the labview resources does not answer my problem.

does anybody already found out more memory leak problems ?

thanks

[Albert.Geven]

The best candidate is an uninitialised shiftregister that keeps growing. 12k/s is quite a lot ! Use the profiler to find the vi that uses so much memory

[ciossek]

thank you i am already using uninitialised shift registers for some global variables. but may be i should do it more often for other purposses.
I have found the vi that used so much memeory. and it was my fault. i have wrote a simulator for some data i will get in the future and forgot to disable it when i changed to an other subject of programming. so the simulator kept increasing an array which i never read.
thanks andreas

[Peter M. Coppess]

I also have a memory leak. You are the second person I have heard mention uninitialized shift registers. Does this cause a memory leak? If so, why? Also, what is the profiler?

[Greg_McKaskle2]

> I also have a memory leak. You are the second person I have heard
> mention uninitialized shift registers. Does this cause a memory leak?
> If so, why? Also, what is the profiler?

An uninitialized shift register can be read from, modified, and written
to. This allows you to store data in memory until you want to access
it. It also allows you to store and store and store data and never
release any of it. If the logic of when to store is not correct, an
array stored in shift registers, locals, or globals, could continue to
grow until it is using all of memory. It is often called a memory leak
since this isn't what the author intended their logic to do, but LV
still knows about the memory, and so does the OS. The memory will be
released
automatically when the VI goes out of memory and when LV is Exited.

The profiler is under the Tools>>Options menu and it will make timing
and memory usage measurements on your VIs to help you track down
problems or optimize operation.

Greg McKaskle

[judith m recca]

I have been seeing similar behavior; I too have not found all the
leaks. I think I have slowed the allocation by replacing some of my
'build array' functions with the combination of 'initialize array'
followed by 'replace array subset'. The drawback to doing it this way
is that you have a fixed maximum number of elements allocated just once
rather than allowing an array to grow incrementally. Please let me know
if you try removing build arrays and if that helps.
By the way, there is a checkbox under the options menu to deallocate
memory as soon as possible - if you don't mind that your program runs
more slowly, this may help to avoid the problem, at least temporarily.
-vinny


ciossek wrote:

> dear all,
> my labview program needs an increasing amount of memo
ry when running
> (at the time about 12k/s) which leads to swapping memory on my hdd.
> i have found out that calling cluster references like Controls[] or
> decos[] leads to this kind of memory leak and made a work around for
> that (simply calling it only once at runtime) but there are more
> memory leak(s)which i cannot find. The bugs that i have found
> searching the labview resources does not answer my problem.
>
> does anybody already found out more memory leak problems ?
>
> thanks

[ciossek]

thank you for your hint to the "build array" functions. i will change some of the more often used build arrays functions and think this may help to make make the program faster.

andreas

[edi]

Have the same trouble. You have to close the references. You do this by
using the Close LV Object Reference VI located in the Application Control
Palette for each item in the cluister.
Regards,
Edi
Edi_001@hotmail.com

[Edi_001]

The solution is to close the references to each control in the cluster in the loop each time you use this reference. I am attaching an example !

[srm@viewpointusa.com]

It is certainly reproducable with getting the refnum to controls within a cluster. It is not clear that not closing the refnum of the property node of the cluster itself causes a memory leak. The NI examples do not close the reference. Can anyone at NI explain which refnums need to be closed?
Stu