how to detect memory leak in labview

[RavensFan]

If you've got 12 hours between tests that only last 2 hours, why not just shutdown the application and restart it when you are ready to begin the next test?

[willholl]

That is my idea - but the whole point of using labview is to make something that doesn't require manual intervention.  I expect to be away from my machine for a week at a time, and it would be nice to know that it could last a week.

This is my first foray into labview, and I really can't quite believe that  labview would rather crash than cleanup it's own memory! or that no-one else is using labview for high uptime applications though, without writing every vi increadibly carefully (i.e. to guru level).

[JÞB]

---

@crossrulz wrote:

After looking at the code a little more, I made this update.

1. Use the FOR loop to do your search.

          You can enable a Conditional Terminal on a FOR loop to abort the loop before it runs through all of the elements.  So you can use that to stop your FOR loop when you found the desired element.  This will actually eliminate the need to build up an array and use the Search 1D Array.  The lack of building an array will help your memory issue some.

2.  Use the In Place Element Structure to index the item you want changed.  Not exactly needed (the LabVIEW compiler does a lot of optimizations), but it makes things a little cleaner.

3.  The Error Ring can allow for inputs for the source.  So you can add a "%s" to the description in the error ring and you will see an extra string input to wire up your search name when it was not found.

---

A few tweaks to improve performance

That Silly case driven by equality is a huge warning!  Just exit the darned loop when you find the Bitfield and the rest of the iterations are unneeded.

For even better performance consider using varient attributes instead of an array of clusters.  Tim, the IPE in this use is not necessary.  The "Magic Pattern" assures the compiler operates in place on that cluster.  The IPE may just slow down the code by adding extra synchronozation barriers.

[JÞB]

---

@willholl wrote:

I've found there are lots of VI's that read in files, pass them through the VI attached, then do some functions before writing out.

---

 How many files are we talking about?  If its one file you should access its data through one Action Engine!

---

Thus unless I write my VI's with the rigour of C (and I'm not sure how to do that), I'll never get a vi to run indefinitiely and we will always run out of memory at some point.

---

C and LabVIEW are entirely different.  LabVIEW has a higher level of abstraction than C.  The Memory Manager in LabVIEW does have a tendancy to reserve memory allocations that it feels it might just need again (And this generally increases performance)  Simply Deallocating memory that may be reallocated later should be used ONLY after looking over the code completely.

[willholl]

Thus unless I write my VI's with the rigour of C (and I'm not sure how to do that), I'll never get a vi to run indefinitiely and we will always run out of memory at some point.

---

C and LabVIEW are entirely different.  LabVIEW has a higher level of abstraction than C.  The Memory Manager in LabVIEW does have a tendancy to reserve memory allocations that it feels it might just need again (And this generally increases performance)  Simply Deallocating memory that may be reallocated later should be used ONLY after looking over the code completely.

---

I completely agree.  C is something that the programmer needs complete control of, and can easily get things wrong.  There are many tools to help with this.

Labview is a high level language that is heavily abstracted, and does not allow the user to control things like memory allocation.  Unfortunately there is the side effect that if you do not understand labview completely then it will crash before it de-allocates memory, thus making it a poor option for any high uptime environments.

I'm struggling, because although there are many helpful people reading & posting to this thread, no-one has been able to suggest any tool that will tell me where the problem is (Neither DETT nor Profile Performance and Memory suggest anything is wrong with my code) .  I've posted one Vi, and that has had a few improvements made to it (thanks for the help with that and I must admit I'm learning labview from it), but I don't yet see anyone telling me that there was a memory issue with the original (and in fact when running with the updated version, I don't see memory growing less fast), so it's probably not the main issue anyway.  I'm not sure I'm able to post the few hundred vi's I'm relying on to get this (I'll spend too much time checking IP can be shared).

Thus not knowing where to focus my efforts, there are, I'm sure many possiblities of improvements, and many techniques that might be worth learning about, but to be honest, I've other things to spend my time on, and it's probably easier to get someone to reset labview every few days over the next several months that this needs to run for, rather than spend a month trying to fix every single VI in turn.

If anyone can suggest how to find where my issue is (without analysing every VI manually) then that would be great.  There does appear to be the "VI Analyser", but I can't find any tests to add to it, or any documentation on how to write a test, and what it should be testing for, so I'm guessing it's probably not usable in my case.

[JÞB]

---

@willholl wrote:

If anyone can suggest how to find where my issue is (without analysing every VI manually) then that would be great.  There does appear to be the "VI Analyser", but I can't find any tests to add to it, or any documentation on how to write a test, and what it should be testing for, so I'm guessing it's probably not usable in my case.

---

The default suite of VI Analyzer tests is as likely to find the source of the memory leak as anything.  Additional tests, and documention on how to add new ones can be found here 

Slight correction to the previous modified code

[tst]

The relevant tests in VI Analyzer should be in the BD section. I believe there's a group of performance tests. Specifically, there's one that checks for building arrays and strings in loops. Make sure you go into the options of the tests, because that one, for instance, does not flag Build Array in a loop if it's in a case structure by default. Another thing to watch out for is writing to queues or enqueuing events and not handling them.

The only generic suggestion I have for pinpointing these types of issues is to disable parts of your code until you can pinpoint which part causes the issue. How practical that is highly depends on how your program is built.

[willholl]

Thanks for the pointers - Unfortunately, whilst I'm told I should have access to the VI Analyser, there are no tests installed, and I can't find any pointers on how to add them.

The NI web pages just say "Included as part of the Professional Edition"

Labview update manager doen't offer anything that looks related (other than upgrading to 2015, which is not easy to do without getting the whole department to do the same)

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

[mr_builder]

First : Labview 2015 does have a new "Profile Buffer Allocation" that records where buffers in arrays are growing . Maybe only use trial version to see if it can help you ?

Second : I am missing a little bit info about the scope of this functions. How much data is it processing, how big are the arrays ? Because I almost think that there is also some code that is causing your memory problem, instead of this VI.

Just to name a few things that can cause these problems  :

- Opening of files, but never closing the reference

- Opening certain references of VI's  / clones but never stopping

- Always creating Queue references but never closing

- Filling of Queue's in a faster rate than reading

- Ever increasing string or arrays in size

[tst]

I'm not very familiar with how VI Analyzer works or when it installs tests. I would have expected them to be installed automatically, so maybe it's something wrong with the installation, or maybe your version isn't LV pro? You could try repairing the install, or look through the documents/discussions in this group to see if there are any relevant suggestions - https://decibel.ni.com/content/groups/vi-analyzer-enthusiasts