memory usage too high

[instrumento]

Executable compiled with Labview 2011 32 bits posts a popup of "Memory usage too high, Program will exit after you press OK. Please restart LabVIEW" on a Windows XP/SP3 machine.

See attached image with Process Explorer outputs for the two Labview executables running, the one that crashes is the one on the left.  Memory usage doesn't seem excessive.

Tried under development, same problem.

Not sure where to look...

[Akiel]

Could a case of you have alot of small amounts of free memory instead of a larger block your vi may need. what does your vi do? in the meantime may be worth looking at the following article. I searched for optimise labview memory

may help

optimise labview memory 

[GabbyG]

Hi

284MB can be very excessive. It all depends of what you are doing in your project.

Remember that a user process under 32Bit Windows has only 512 MB on its disposition. Within these all stack and heap area must also fit in.

From my experience 200MB is safe, but allocating some extra area (by copying a large arry or so) will trip it quickly.

There are some howtos in the support  area. But you may come back with some more information of what you are doing.

Good luck

Gabi 

[GabbyG]

Hi

Let me correct my numbers.

For all you should add a gigabyte.

That is the process has usally 2GB. you can start a special version of Windows where user processes can have 3GB.

Every process (.exe) has to fit into this nomatter how many RAm is there.

So roughly 1200 MB is a good guess to where a LV-program can savely go.

[instrumento]

The code in question is part of our core system that runs several of our test systems in one incarnation or another.  At the point where this particular one is crashing the code is probably 90%+ identical between all of them.  Also, at that point, 300 Mbyte size is not unreasonable and yes, if there are leaks and the code aproaches 1.2G we will run out of memory, but never with the numbers that this one shows.

That same core code runs fine in LV7/32, WinXP/SP3 bits in other systems.  It was initially ported to LV2009/32 and then 2010/32 bits, WinXP/SP3, and runs fine (on that same machine) in executable and LV2010/32 development.  That same core code runs fine in LV2011/64 bits, Win7 machines.  I am now trying ro update the machine in question to LV2011/32 and found that problem.

I don't believe LV is running out of memory but that something else is triggering it (maybe some external DLL ...) but the code does get to our main GUI where we launch the test from, and at that point it is apparently idle waiting for user input, when the dialog shows up.

[DFGray]

Running out of memory can be a very flaky thing subject to exactly what is is running at the same time.  Arrays in LabVIEW must be continguous in memory.  The side effect of this is that if your memory is highly fragmented, you can run out of memory far before your actual memory is gone.  I would recommend you read Managing Large Data Sets in LabVIEW or the equivalent LabVIEW help topic for details on the limitations of 32-bit LabVIEW.

LabVIEW programming practices which fragment memory include anything which uses the memory manager.  Usually, problems occur with repetitively allocating memory in a loop, such as using a build array or concatenate string in a loop.  These things are fairly easy to refactor to avoid the problem, and you will get much better performance, as well.

If you can post some or all of your code, we can offer better suggestions.  Good luck!