LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

how to diagnose an out of memory error

We have a client running our LabVIEW 2018 program (compiled) on W7, 32bit. They run 24/7, and every 4 months they get error 2, out of memory from our program. (There are two other programs running as well, written in an older version of LV that don't exhibit problems.) Our program is very modular, and except for a couple of custom modules, we've run it on numerous other systems without seeing any such error. So I set up a computer here to run just those two modules. No obvious memory leak. Also, when LV start reporting Error 2, Windows still says that our program is only taking up about 140MB, and there are 600MB free memory! So it really doesn't look like a traditional memory leak out-of-memory error.

I'd like them to try replacing the memory chips, but the system is remote, with limited physical access.

My questions are:

Does anyone have experience with similar symptoms in which it turned out to be the memory hardware was bad, not the software?

Stated another way: Do the symptoms described sound like they could be due to bad memory chips?
Also, any recommendations for a diagnostic program we could run that could check the chips?

Thanks,

    DaveT

-------------------------------------------------------------
David Thomson Original Code Consulting
www.originalcode.com
National Instruments Alliance Program Member
Certified LabVIEW Architect
Certified Embedded Systems Developer
-------------------------------------------------------------
There are 10 kinds of people: those who understand binary, and those who don't.
0 Kudos
Message 1 of 7
(1,054 Views)

LabVIEW needs contiguous memory.  It's likely that arrays are being built and destroyed in a way that leaves holes in your memory.  Eventually the arrays can't fit into whatever holes are left and you get the error 2.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 2 of 7
(1,045 Views)

Was there a function referenced in the out of memory error that caused the error? For testing the memory chips you can try with memtest86.

Lucian
CLA
0 Kudos
Message 3 of 7
(977 Views)

It can be a false error. If something else, like a DLL, generates error 2 LV will say Out of memory. Otherwise the Profiler might be able to tell if something slowly eats memory.

G# - Award winning reference based OOP for LV, for free! ADDQ VIPM Now on GitHub
"Only dead fish swim downstream" - "My life for Kudos!" - "Dumb people repeat old mistakes - smart ones create new ones."
Certified-LabVIEW-Developer
0 Kudos
Message 4 of 7
(969 Views)

I still say that the most likely problem is fragmented memory.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 5 of 7
(922 Views)
  • Do the symptoms described sound like they could be due to bad memory chips?
    • It seems unlikely that the cause would be bad memory chips. If that was the case then presumably the two other apps written in an older version of LV (and other Windows apps too) would experience the same (or similar) error and/or timing of the error (once every 4 months).
  • Any recommendations for a diagnostic program we could run that could check the chips?
    • A program that may shed more light on the LV app that experiences the error is Process Explorer from the Windows Sysinternals suite of utilities. It is like a much more advanced version of Task Manager, Resource Monitor or Performance Monitor. In Process Explorer, you can right-click on the LabVIEW app and select 'Properties'. Then navigate to 'Performance Graph' (there may be no need to navigate to this page, as it might be the one that meets you when you open the properties). The 'Private Bytes' plot in that page may give you insight into whether the memory usage keeps increasing.
Message 6 of 7
(887 Views)

@Dave_Thomson wrote:

We have a client running our LabVIEW 2018 program (compiled) on W7, 32bit. They run 24/7, and every 4 months they get error 2, out of memory from our program [...]


OK, this may be a really long shot, but I saw a similar multi-month-memory-issue with an application I interacted with a lot (this was before I was programming in LabVIEW - the application was written by a professional developer, and the application was generally very good).

 

The issue (from a user perspective) came from a log file reaching a certain size, about (IIRC) 2GB. The computer had plenty of extra RAM and hard-drive space, but the application couldn't write to it anymore. I haven't seen the source code, but I suspect the whole file was being read into LabVIEW before writing, so that it was entirely in memory. Again, at the time, I was just a user, so I'm not sure of the root cause in our case, but our workaround was to rename the log file every few months.

 

If it's related, maybe this can point you in the right direction (or maybe this doesn't help at all, or points to @billko's answer(s)), but that's what I've seen, for what it's worth.

 

-joeorbob

 

 

0 Kudos
Message 7 of 7
(834 Views)