Finding Memory Leak in LabVIEW

[Sebastian Dau]

Hi NG,

we wrote a sort of hugh application in labview that collaborates with our
..NET driven
device framework and a variaty of unmanged c++ libs.

As we are now close to the release we did performance testing and it showed
up that
the app is consuming more memory continously.

We used prefomance counter to check whether the managed objects might not
get garbage collected
but this is done OK, since the handle count stays at a constant level.

We tried to figure out whether one of the c++ libs is causing the problem
but this is not the case either, since
the memory leak exists even if the lib functions are just not being called.

Even labview profiler is not detecting any inconvenient memory consumption
of any of our vis but
windows task manager notices a constant memory consumtion of the executable
(or of labview.exe itselve when running in
dev. environment).

Does anybody know what this might be? Has anybody a clue what other tools we
could use to figure out
where the problem is?

Any help is greatly appreciated.

Thanks in advance, Sebastian Dau!

[mfitzsimons]

Sebastian,

Memory leaks can be VERY hard to find.  I use the divide and conquer technique that involves chunking (make into smaller code segments) your code into smaller pieces and running the smaller pieces until you find the memory leak.  It can take weeks to find the source.

The most common is arrays or any data that increases in size as the program runs.  To fix this you can use a FIFO that allows only so many elements to be added before deleting data out of the array.  The second source is opening references repeatedly and not closing them.  Look closely at any VI that open anything.  Do a search for "Memory Leak" on the discussion forum and you will find about 60 postings that may help. 

Matt

If you are using DAQ-MX http://digital.ni.com/public.nsf/allkb/BAF29EE03747EE4B86256E9700541436?OpenDocument

[Sebastian Dau]

"mfitzsimons" <x@no.email> wrote in message
news:1134564040595-299810@exchange.ni.com...
> Sebastian,
> Memory leaks can be VERY hard to find.&nbsp; I use the divide and conquer
> technique that involves chunking (make into smaller code segments) your
> code into smaller pieces and running the smaller pieces until you find the
> memory leak.&nbsp; It can take weeks to find the source.

you accelerate this process by using the labview profiler.

> The most common is arrays or any data that increases in size as the
> program runs.&nbsp; To fix this you can use a FIFO that allows only so
> many elements to be added before deleting data out of the array.&nbsp; The
> second source is opening references repeatedly and not closing them.&nbsp;
> Look closely at any VI that open anything.&nbsp; Do a search for "Memory
> Leak" on the discussion forum and you will find about 60 postings that may
> help.&nbsp;
> Matt
> If you are using DAQ-MX <a
> href="http://digital.ni.com/public.nsf/allkb/BAF29EE03747EE4B86256E9700541436?OpenDocument"
> target="_blank">http://digital.ni.com/public.nsf/allkb/BAF29EE03747EE4B86256E9700541436?OpenDocument</a>
> &nbsp;
>

arrays and refs have already been checked.

thanks, Sebastian

[Ben]

Have you tried using the VI Profiler?

Ben

Message Edited by Ben on 12-15-2005 07:36 PM

[Sebastian Dau]

"Ben" <x@no.email> wrote in message
news:1134697252115-300717@exchange.ni.com...
> Have you tried using the VI Profiler?


I Wrote: "Even labview profiler is not detecting any inconvenient memory
consumption "
in the main thread.

greets, Sebastian Dau

[Neil.Pate]

great response to kill a thread

sebastian, in my limited experience I have found it does not help to be snappy with the people who are trying to help you

[2_tank_dive]

Sabastian,

I am having the same memory leak issue in my LabVIEW GUI.

I am also accessing .NET dll calls, but within a TestStand sequence. My LV code is an operator interface that calls TS, sets up the environment, and then hides the TS code while running so that the only thing the operator sees is the LV GUI.

I exchange fileglobals and pass UI events to the GUI.  The GUI is an event driven while loop. The GUI remains open until the operator hits the internal EXIT button. All events are unregistered and references closed before this GUI is allowed to exit.

However, the GUI memory is growing over time. After the GUI reaches almost 1GBytes, the object references I use for .NET dll calls is suddenly lost. I suspect this is due to Windows can't manage the object reference in memory with LV consuming all mem.

I also and ready for a Beta release at an international contract manufacturing site. This GUI code was developed by another person that I had to inherit, so I am just getting familiar with the logic.

I suspect I will have to file a help ticket with NI to get this resolved.

Thanks for sharing Sabastian, LV memory consumption is a big customer problem.