Memory Leak?

[Cathryn]

I'm having a strange problem with my VI, and I suspect that at least one of the reasons is that there's a memory leak.

Basically, the function of the VI is to send initialisation data to a device via a C DLL, and whenever the dll sets an occurrence, to read data back from the dll. If no occurrences are seen for a certain amount of time, the VI times out and reports an error.

The problem first arose because sometimes the VI would work perfectly, and other times it would only see the first few occurrences. Eventually I realised that it was related to how long LabVIEW had been running: past a certain amount of time, my VI would only notice occurrences slowly - eg. every 1s instead of every 10ms or so. Notice that this isn't related to how long the VI itself has been running, just how long LabVIEW has been running - or in other words, how long the VI has been loaded in memory for.

Trying to investigate further, I discovered that the as the VI runs, the amount of memory that LabVIEW is using (as measured by the task manager) increases steadily - at some points, up to 1Mb per second. Which indicates a memory leak - but the profiler doesn't seem to show anything odd. In addition, when the VI stops running, the amount of memory being used by LabVIEW drops, but not to the level that it was before the VI was run - generally, there's a leak of about 5Mb or more. I assume that this gradual loss of memory between VI runs is what is causing the initial slowing down process that I first noticed.

I managed to strip down the VI to a point where there is no memory leak (basically simulating occurrences in one loop, and detecting them in another), but as soon as I bring back anything real I get the memory leak back. I've looked for every leak source that I can think of, but can't find anything. For example:
- no uninitialised shift registers
- no "build array" calls
- no open calls without corresponding close calls (in fact, no open calls at all)
- no refnums are being used
- no property nodes are being used

I've tried to cut down on the number of parameters that I pass out of a loop, since that is implicitly building an array, but nothing seems to have helped.

I would post a sample VI, but there are a number of complex subVI's that are needed, and I'm not sure if I can cut it down enough to be simple enough to read while still illustrating the problem.

[Evan]

Wow, memory leaks are always a hard one to find. I'll give some ideas that I hope help.

You mention that the memory increases in the VI even if it is not running. Do you mean that simply opening LabVIEW and then the VI without running it causes a memory leak? Are any of the VIs set to run when loaded?

Have you tried to call the dll in C with out LabVIEW and see if the memory leaks there? Is there a chance that the dll is "leaking"? If the leak is in the dll windows will still show LabVIEWs memory increasing. Following the same debugging idea have you run your VIs without calling the dll and rather just passing dummy data around? Does it leak then?

[Cathryn]

Let me explain what I meant about memory usage increasing even when the vi isn't running. I've narrowed the leak down to a single subVI. If I enclose this subVI in a test vi, where all it does is call the subVI and then loop until I press stop, the memory usage keeps increasing during the loop even though the subVI is no longer running. It's not the loop itself that's the problem, because if I do the same thing with a different subVI there's no leak.

I have called the dll in a C program to test it, and there doesn't seem to be any leak there. The leak doesn't seem to be in the dll call, because as you suggest if I leave out the call and use dummy data the problem still exists. I've attached the vi that I think the leak is in - it contains anothe
r subvi, but again, calling that one on it's own with dummy data doesn't solve the problem, so the leak can't be there.

[shoneill]

I can`t open the VI, I`m working with 6.1. However I have trouble following your reasoning, or maybe I misunderstood something.

I`ll refer to the VI you posted as VI 1, the sub-VI in VI 1 as VI 2.

You write that VI 1 "contains another subvi, but again, calling that one on it's own with dummy data doesn't solve the problem, so the leak can't be there". If you refer to calling Vi 2, then the fact that calling this on its own NOT fixing the problem means that the problem IS most likely there....

The other possibility is that you are referring to calling VI 1 without calling VI 2 which, by NOT fixing the problem, means that the problem is buried somewhere inside VI 1.

Hope this helps (and doesnt add to any confusion)

Shane

[Cathryn]

Sorry, I confused myself there. Calling vi2 by itself (i.e. not embedded in vi1) does NOT result in increasing memory usage, i.e. it does solve the problem (opposite to what I what I said above!) so the problem isn't in vi2.

Equally, calling vi1 with a dummy vi instead of vi2 does not solve the problem, i.e. it memory usage keeps increasing, so the problem must be in vi1.

Sorry for the confusion, but thanks for helping me clarify that for myself! 🙂