Tracking down memory leak

[NiAchilles]

Hello, so I am working on a VI at work that somebody else created.  The code is a fairly simple DAQ program that stores data locally and remotely.  About half of the times that I run the program, it runs for a little while and then crashes with a message that says "not enough memory to perform this operation."  I checked Windows Task Manager and the memory used by the VI quickly grows by about 800KB per second until it reaches about 2.4GB and then crashes.  I checked the size of every array and that is not what the issue is and I used LabVIEW's Profile and Performance and Memory manager and took a snapshot of all the VIs.  I don't use this tool often so I'm not sure if there are any clues there but I would welcome some help.  I cannot share the code because it is proprietary but they put a stacked sequence inside of a while loop that continuously takes samples of data and stores it.  It is running on Windows 7 and using LabVIEW 2014.  It is important to note that this does not happen every time.  Sometimes the memory usage is constant and there is no issue.  Thanks for the help.  

[Ben]

You have not given much of a chance of helping you.

This link to tags about memory may hold the answer.

Run VI Analyzer and it may find something obvious.

Since it looks like you are doing FFTs etc. then check any queues that are used to see if they are backing up.

It all else fails, start whacking away large parts of the code until the leak goes away. Whatever you whacked last, may be related to the memory loss.

Ben 

[ogk.nz]

Are there any inputs that you can select to determine what data is to be used/rates etc? Does changing any of these values create a difference to how the program reacts?

Are there any unlimited sized queues present in the program? These can often take up a large amount of memory if the program is enqueuing items but not dequeuing them at a faster rate.

How is the remote storage done? If the system holds onto its data until it can store it remotely, then a failure to access remote storage could explain the memory increases.

[altenbach]

---

@NiAchilles wrote:

Hello, so I am working on a VI at work that somebody else created.  The code is a fairly simple DAQ program that stores data locally and remotely.  About half of the times that I run the program, it runs for a little while and then crashes with a message that says "not enough memory to perform this operation."

---

This is definitely not enough information to say much. Was that "somebody else" a beginner or a seasoned professional? Does the code look reasonable overall or is it a mess (deeply stacked sequences, abundance of local variables and value property nodes, diagram much larger than screen, gratuitous use of dynamic data and express VIs, etc.) ?

Are there uninitialized shift registers? Does it constantly open new references without ever closing anything? What are the history sizes of charts. How does it store the data locally (in a file? in a data structure?). If it writes to a file, does it keep the file open for the duration of the run?

[NiAchilles]

Thanks Ben, I will look into using the VI Analyzer.  What other information would be helpful?  

[NiAchilles]

The person who wrote it was more than a beginner but not by much.  The code is ok, not great but there are no local variables and the code looks reasonable, it is easy to follow.  There are no express VIs, no dynamic data, and it all fits on one screen which is nice.  The data is written to a binary file that is only closed once the code stops running.  It uses the same file references every time. 

The odd thing is that this happens intermittently.  If it happened every time, it would be easier to track down.      

[Ben]

---

@NiAchilles wrote:

Thanks Ben, I will look into using the VI Analyzer.  What other information would be helpful?  

---

1) See the tags I linked for situation where we helped people find and fix memory problems.

2) Post the code for us to review. Who in their right mind would want to steal proprietary code that crashes anyway?

See the other  items I suggested and the post by the others.

Ben

[JÞB]

---

@NiAchilles wrote:

Thanks Ben, I will look into using the VI Analyzer.  What other information would be helpful?  

---

Why you are using Express.vis would be an asset.

(Yup, I believe I see an Express.vi in the Profile snip)

Why not the whole report?  Possibly even a Snippet of the top level vi.  Perhaps a zip of the project source and descriptions of the DAQ configurations?  Yeah, most of that would enable us to help you a lot better.

[NiAchilles]

---

@ogk.nz wrote:

Are there any inputs that you can select to determine what data is to be used/rates etc? Does changing any of these values create a difference to how the program reacts?

Are there any unlimited sized queues present in the program? These can often take up a large amount of memory if the program is enqueuing items but not dequeuing them at a faster rate.

How is the remote storage done? If the system holds onto its data until it can store it remotely, then a failure to access remote storage could explain the memory increases.

---

Thanks, no there are no inputs to adjust.  All of the inputs are from an NI card collecting analog data.  

There are no queues.

The remote storage is done after every cycle.  The system takes 1000 samples,  does some math, displays it on a chart, stores the data to a binary file, stores it on our network, and repeats.  

[Hooovahh]

Yes please post the code if you can.  That being said I'm going to bet it is file references not being closed, but new ones are opened.  Is there VI references being opened?  Is there image manipulation or generation?  Are arrays using a build array function but never having an upper bounds on the size?