Incorrect and inconsistent data memory usage

[Richard2950]

I have a  vi that I am running under LabVIEW 8.6. Most of the time the memory usage  is listed as :
Front Panel Objects                  184.7

Block Diagram Objects             696.3

Code                                       145.3

Data                                       2726.1

Usually when I run the vi the data usage goes up by about 20 K then stabilizes. About 1 time in 10, though, when I run the vi the data usage goes to greater than 1.5 Gigabytes and LabVIEW usualy crashes or misbehaves after that. This happens within seconds, using the same default values that usually work fine. I don't think this is a case of memory leaks or memory mismanagement because the memory use should be the same every time the vi runs, and there is no way it can go that high that fast. If the vi runs OK once, I can stop it and start it and run it forever with no problems and no increase in memory use. If it shows the high memory use once, then everything is hosed until I restart LabVIEW.

What could cause erratic behavior like this? I have tried it on two different computers with the same result. The vi is a bit complex, so it would be difficult to post it here.

[Norbert_B]

Without the code this question is nearly impossible to answer. In my experience, LV does not simply eat up memory like this on its own. Never seen this.

So here my assumption: 

You handle large memory sets and there is a possible race condition in its access leading to several copies of the data set. So getting rid of the race condition is the way to get rid of the memory hog.

Please post the VI in order to do some proper analysis. Everything else is pure speculation..... 

hope this helps,

Norbert 

[Richard2950]

The suggestion of a race was a good one, but it turned out to be something else. After spending a whole day ripping out pieces one-by-one and restarting over and over I finally narrowed it down to the initialization of an external library. That still doesn't explain why it is inconsistent, but at least I know now that there is nothing I can do within my vi to solve the problem. I have found  a workaround by initializing the library with a tiny vi and then calling the big vi. So far I have had no problems with that, so I am hopeful that will work consistently. In the long term I need to find a way to dump that library.