Late Run Memory Leak

[ogk.nz]

Hi,

I'm not particularly hopeful that anyone will have any ideas about how to resolve this probelm but its worth a shot as I'm running out of ideas.

For one of my projects I am overseeing a long-term data-logger for scientific trials, I inherited this code and have had an ongoing hand in maintaining it but am not completely intimate with it yet, but during the last trial run the program crashed and presented with the error messages:

After restarting the program I have been tracking its memory usage to see what is happening, and for the first 5 days or so the memory usage was pretty low at about 200 - 400 MB however there was then a sudden jump and it is now sitting at around 1200 - 1400 MB, considering that the computer it is running on only has 2GB of RAM I am expecting the next sudden jump to cause the memory errors again and stop the program. 

Is there any reason that you can think of that would cause these sudden jumps in memory usage? Given the nature of the sudden jumps I am a little confused as I would have expected most memory leaks to slowly increase the drain on the computers resources rather then taking sudden leaps. I have tried running the program on my computer but due to the lack of nearly all of the attached componentry the program has been unable to run correctly. Given the slow and seemingly random nature of these memory surges I have been unable to track down even the source VI. Sorry I can't attach a VI but the program itself is made up of over 100 VIs and a couple of 100 MBs in size. 

Any ideas for possible causes would be greatfully accepted.

[altenbach]

Did you sent the error report to NI?

[ogk.nz]

Yep, We have sent the error report and contacted them and they directed us to:

https://www.ni.com/docs/en-US/bundle/labview/page/vi-memory-usage.html

and:

http://digital.ni.com/public.nsf/allkb/771AC793114A5CB986256CAB00079F57 

Having looked over both I can't see any immediately helpful information. I have gone through and tidied up what I can, closing references etc but I won't be able to tell if it makes any differece until I reinstall the program which I am going to have to wait to do once the current experimental run finishes.

[altenbach]

It would be very interesting to know what happens when the memory suddenly jumps. Is there anything in the code that gets called rarely?

Typically, te memory would build up more slowly over time.

[Norbert_B]

As memory consumption stays rather stable for an extended timeframe, you should use PerfMon to log key counters of the application and system during execution.

I expect that there is more than just a memory issue here...

Norbert

[M_Peeker]

One thing that comes to mind is if some memory is allocated based on some variable that overflows, e.g 255+1=0 using U8?

The fact that it jumps after a lengthy time might indicate that some sort of counter does this.

[altenbach]

I agree with Norbert that there are probably other issues, but I am not sure what perfmon is. Are you talking about this document?

What does the program do in detail? Is there network communication involved?

Do you have access to the Desktop Execution Trace Toolkit? (see also)

[Norbert_B]

---

@altenbach wrote:

[...], but I am not sure what perfmon is. [...]

---

I am talking about the Windows Performance Monitor tool. It is very suitable to track down general issues with an application as you can observe many "performance counter" like thread count, private bytes and such.

Once you have some basic information on the general issue, you can dig into the application using application specific debugging tools. DETT is the one you would use for LV applications in this situation, indeed.

Norbert

[ogk.nz]

Yeah, I might have to have a look with PerfMon and see what is going on. Although on that line of thinking, does LabVIEW have the ability to monitor its own memory usage? So could I write a little addendum to the code which regularly checks the memory usage of the program and records it somewhere, a higher detail map of when the problem is occurring might help to narrow things down a little.

[RavensFan]

Never Mind.  I missed a later reply.