how to detect memory leak in labview

[altenbach]

---

willholl wrote:

Does anyone have any hints on how I might be able to find the tests?

---

Did you select VI analyzer when you installed LabVIEW?

[JÞB]

The path should be C:\Program Files (x86)\National Instruments\LabVIEW 2014\vi.lib\addons\analyzer\

and contains:

If those files are missing you will need to reinstall VI Analyzer.  Its possible that you unchecked the component when installing LabVIEW originally.

[willholl]

Thanks.  I've found the link to the VI Analyser (

http://ftp.ni.com/evaluation/labview/ekit/other/downloader/2014VIAnalyz-Win.exe) so I'm now downloading and will start running the analysis shortly.

I may trial 2015 to see if the "Profile Buffer Allocation" helps.

The amount of data I'm creating is quite small.  At the moment I'm concentrating on stability testing, so I'm looping every 2 hours, but I'm only creating a single CSV of 132k each test.  There is one VI for creating the file data (one line at a time), and it defintiely opens and closes the file reference properly.

I would have expected that DETT would have caught references being left open (it definitely found 1 early on that I fixed prior to opening this thread).

There is no "Queue" as far as I know - I create an array of the commands to step through at the beginning of the run, and then step through them, one at a time.  For each command I create a string once I've completed the measurement, and write it to a file.

I'll post any results from the VI Analyser once I've got that running.

[mr_builder]

1 ) Note that DETT only shows the "not closed references" when the Main VI / application has stopped. Before that time it it still possible that you do something with the reference.

2 ) There is a "TaskManager Example" which allows you to retreive CPU and Memory usage. Maybe you can log with a 5 minute inteval the memory usage ?. Does it occur gradually, or each hour when you write the data to file ?

3 ) Can you post the "write to data" VI'

4) I think you have more need of a Human analyser then a VI Analysing, maybe a colleague with a fresh look can help ?

[Yamaeda]

If you can handle pointers in C, you can easily fix this, though it's a bit scary to let go of the detailed control. 🙂

One classic with growing memory if repeatedly opening and closing references. It's not a leak per se, but LV will allocate new memory and it'll fragment and cause memory growth.

If you only open and close the file ref every 20 min it's a none issue, but if it's part of the ordinary loop (at say 50ms) it'll quickly grow.

Over abuse of Local variables and Property nodes can also cause some issues, but usually not to this extent.

/Y

[willholl]

So I've found 1 string in a loop.

It is run as part of the CSV Conversion prior to writing the result, so fairly regularly.

I don't see how this could actually be an issue though - it's defined in length, so it should not grow indefinitely?  Or is this likely a real issue?

I Guess the recommended strategy is just to have one massive concatenation?

[Yamaeda]

IF it'd been an uninitialized shift register it would be a problem. Since this isn't, it isn't a problem. 🙂

That's another common problem, uninitialized shift registers in the wrong place. They'll simply grow with each call.

/Y

[willholl]

Thanks for the suggestion.

Yes, I'm opening and closing a file reference every few seconds (within the measurement loop), as I write out a result every time I do a measurement.  I guess I could make this persistant, for this application, but as I'm re-using code, generally we don't want to lock the files more than necessary.

Again, there are some local variables that are created at a similar rate (e.g. creating the string that's written to the results file in my previous post), so these may be causing the fragmentation, and thus the memory failure.

I'll have a think about how best to re-write these.

[Yamaeda]

---

@willholl wrote:

Yes, I'm opening and closing a file reference every few seconds (within the measurement loop), as I write out a result every time I do a measurement.  I guess I could make this persistant, for this application, but as I'm re-using code, generally we don't want to lock the files more than necessary.

---

If you want to make reusable file handling code, it's a good idea to use File ref for inputs and outputs (as most of the built in function has), then it's easy to use a Open-Modify-Close design, with the Open and Close outside of the main loop (or in separate states if using a state machine).

/Y

[crossrulz]

---

@willholl wrote:

So I've found 1 string in a loop.

It is run as part of the CSV Conversion prior to writing the result, so fairly regularly.

I don't see how this could actually be an issue though - it's defined in length, so it should not grow indefinitely?  Or is this likely a real issue?

I Guess the recommended strategy is just to have one massive concatenation?

---

I would just use Array To Spreadsheet String.  The growing of the string inside of a loop could be an issue, even if it is the same length each time.