Labview's memory usage is increasing slowly but continuosly during runtime

[eme]

Hello,

I'm having some trouble with LabVIEW. I'm developing a data acquisition application. My application acquires data, processes it (this means doing a FFT), and displays the FFT as well as the acquired samples in some graphs.

The problem I encountered is that Labview is allocating more and more memory every minute my program is running till it finally crashes. When starting my program uses about 400MB of memory after 4 minutes about 1.2 GB. Somtimes when the memory usage reaches 1.2 GB it suddenly falls back to 500MB but most times Labview crashes.

I already checked the "Profile Performance and Memory" tool. Surprisingly my VIs have constant memory usage during runtime.

Does anybody have an idea what's going on?

Regards,

eme

[PauloM]

Hello,

Normally that's a sign that you are openning references in cycle and not closing them.

It can be also charts with very large history.

But I would bet on the first guess.

How are you doing your DAQ handling? Is it continuous? Do you open the DAQ referenxe every cycle? Do you exit the acquisition cycle on error? Do you close the refrence in case of exiting the loop?

Hope this helps,

Paulo

[xdaf]

PauloM is right.

1) If you're running a DAQmx task inside a loop, move the "create task" VI outside the loop, and leave only the "run/play task" inside.

2) Once you're done with the task, use the "clear task" VI from DAQmx palette.

Regards

[eme]

Hello,

I don't think that the charts are the problem. I'm using 7 charts with  a history length set to the default value of 1024.

Indeed the sample mode is set to "Continuous Samples". But I'm running the "Create Task", "Create Channel", "DAQmx Timing" and "Start Task" VIs outside the loop. So they are just called one single time. The only DAQmx VI inside the loop is the "DAQmx Read" VI. I also use the "Clear Task" VI  after exiting the loop. Although the DAQmx Task is not cleared in case of an error  I do not believe that this would cause the problem, because  memory usage is increasing even when no errors occur.

I checked the "Profile Performance and Memory" tool once again and discovered that the main VI is using all the memory. This is quite surprising since I'm running everything in sub VIs. No loop and no data acquisition task is runnung directly in the main VI. It just serves to pass references to some buttons and the graphs to the sub VIs and calls the sub VI that handles the data acquisition.

Do I have to close the references to buttons and graphs as well after having changed their values?

Regrads,

eme

[xdaf]

Can you post your VIs, so we can help to find who's allocating memory without releasing it?

[Broken_Arrow]

Other possible memory leak:

• Building arrays in loops over a long time.
• As above, but Concatenating Strings.
• Improper use of Insert Into Array.
• I've also seen 2nd party .NET calls (such as a LabVIEW "driver" for a piece of hardware) and LabVIEW bugs cause memory leaks.

I hate when I hit Post before hitting Check Spelling

Message Edited by Broken Arrow on 04-08-2010 08:23 AM

[Joseph_Loo]

It could be a combination of windows and Labview. I have an application that runs weeks at a time. I notice that the free memory goes from 78 MB to 200 MB over days at a time. During the low periods, I suspect that the memory has not been garbage collected by LabView.

At startup during my application, I reboot and login into the machine. I find that the IT organization places a lot of applications on the computer and see a large reduction of free memory during startup operation. It requires normally a wait and restart before the application will run.

One thing that is critical you did not mention is how much free memory you have available during the run and the amount of physical memory. You could be swapping a bit and cause other issues. Another thing, you don't mention if the crashes occurs at the initial login, bootup etc. If you have a lot of applications running you could have memory leaks in other applications that could cause the issue.

[eme]

The whole application has about 150 VIs I'm not sure if it's very useful to post the whole application. Nevertheless I can post it of you want. I'm not building arrays on loops over a long time but I'm doing something similar. The data acquired is actually buffered in a shift register of a for loop. I'm using the "Append Waveform" VI to do so. But the buffersize is limited. There is a VI that truncates the buffer every times it grows bigger than a given value by using the "Get Waveform Subset VI". Can this cause any problems?

I have about 1.3 GB of free memory available during the run the amount of physical memory is 2.72 GB, the swap file is limited to 4GB. The crash occurs when the system is already up for some time. With the exception of Internet Explorer there are no other programs running.

Regards, eme

Message Edited by eme on 04-08-2010 08:48 AM

[xdaf]

It may be, because it allocates a new buffer, and doesn't dispose old one.

Maybe you can post just the main VI?

[Broken_Arrow]

---

eme wrote:

[...] 

The data acquired is actually buffered in a shift register of a for loop. I'm using the "Append Waveform" VI to do so. But the buffersize is limited. There is a VI that truncates the buffer every times it grows bigger than a given value by using the "Get Waveform Subset VI". Can this cause any problems?

[...]

---

Write a new version of your program that doesn't do that function (use disable structure, etc) and see what happens. It sounds fishy. Getting a slice of data doesn't mean reallocating memory of the things it's not slicing. (hope that made sense)