From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Memory is full. ERROR

Hi,
I'm trying to run my VI, then after it gets a data update it all of a sudden stops executing and this error comes up:
Memory is full.
VI "My.vi" was stopped at node xxx of subVI "Draw Flattened Pixmap.vi"

I've ran my simulation many many times and this is the 1st time I saw this error, any ideas how to solve it...please help.
0 Kudos
Message 1 of 4
(2,809 Views)
Look for a FOR loop that has its N node tied to either a floating point value or something calculated from a floating point value. A very common reason for this type of error is a floating point calculation that results in NaN, Inf or -Inf. When these values are tied to the N node of a FOR loop they get coerced to I32s resulting in either 2147483647 or -2147483648.

Inside the loop will be something that requires LV to allocate memory. The error message is caused when LV can't allocate enough memory for 2 billion iterations.

Mike...

PS: The reason you're seeing it now is that something has probibly gone south in your system and you haven't noticed it yet... This happens a lot and is a good reason for being very, very picky about your error handling.

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
Message 2 of 4
(2,809 Views)
Thank you for the reply, but I just have one thing that I hope you can clarify, when you state:
"either a floating point value or something calculated from a floating point value"
I'm not really sure what I'm looking for / how to fix it. I have gone through my VI with all of it's subVI's to find some 30 instances of for loops, and as for what is wired to the N terminal its either an I32 constant (no problem there I assume), an I32 control (this would be an input to the subVI and on the main VI its a constant) and the 3rd case is where there is nothing wired to the N, but the array that is passed into the for loop is set to auto-indexing so I was under the impression that nothing needs to be wired to the N terminal (the for loop would just do as many iteration
s as there are rows in the array 2D). So judging as to how that's what I have can you please tell me if it sounds alright or if I need to correct something?
0 Kudos
Message 3 of 4
(2,809 Views)
The routine referenced in your original posting is a part of what used to be called the Picture Toolkit. It contains a FOR loop that is accumulating a string. The question is how large the input color table is because the loop repeats once for every value in the array.

Try this: Place a breakpoint on the color table array wire going into the FOR loop. Make sure that this breakpoint is inside the case structure but outside the loop. You want the code to break before the loop is started.

Next, put a probe on the output of the array size function that's tied to the color table array and minimize (NOT close)everything, and run your code. When execution hits the breakpoint, LV will bring the diagram to the front.

If the program crashes befor
e reaching the breakpoint, we know to look elsewhere. If it doesn't crash before getting to the breakpoint, verify the size of the array coming into this subvi, as reported on the probe. I would expect a very large number.

If you see a very large number, backtrack to the routine that's calling this one to see where the morbidly obese array is coming from...

If you don't see a large number on the probe, turn on execution highlighting and click the continue button and watch for what the code is doing when the crash comes...

Alternately, if the code is small enough (and you are willing) I would be willing to look at it to see if I can spot the problem.

Hang in there. This is an interesting problem, but on the whole not too bad of a one so far. Extremely irritating, yes. Bad, no.

Mike...
mporter@arielcorp.com

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
Message 4 of 4
(2,809 Views)