Confusing Memory Growth in Intentionally Bad VI

[Jorr-El]

Ok, so I know that this is horrible programming practice, but I am making an "example application" that has configurable coding flaws that cause common problems - memory leaks, high cpu usage, silent/unhandled errors, etc., as a LabVIEW debugging exercise for new engineers using common debugging tools.

I ran into a strange issue where LabVIEW's memory growth seems backwards. Let me explain.

If I run this VI, LabVIEW's memory on my computer grows rapidly until I get an error saying LabVIEW is out of memory, as it can't reserve more than 3 GB. LabVIEW will run out of memory in ~5s (~150 MB to 3,300 MB in that span of time).

However, if I make the problem even worse by adding in another Build Array inside the while loop, the memory grows much slower (about 10 MB/s), which is the opposite of what I'd expect.

Can anyone help make sense out of this? I guess this isn't a serious request for help, but more of a curiosity for me, since this seems to fly in the face of what I would have expected it to behave like.

EDIT: I added loop timing (just a simple Wait (ms) in the loop), and the upper version of the code still piles up memory much faster than the lower version

[Kyle97330]

Can you post the actual VIs?

I know you posted snippet PNGs, but it looks like the forum compressed them, which drops the metadata containing the G code.  I think you need to either attach them as files instead of inline pictures, or if you post them as inline pictures make sure to set them to the "large" size which might stop it from compressing them.

[altenbach · Accepted solution]

Yes, we really need to see the actual VI (including all settings, debugging, etc.)).

Why is the shift register initialized with a non-empty array? What's in it? How big is the array that gets multiplied the the random number? (container size != array size in general).

Your second code really does not make anything "worse" because that uninitialized(!) shift register and all related code will be tossed by the compiler as dead code (Unless you have debugging enabled and plan to probe that wire).

What is [i] when it runs out of memory for the two scenarios?

[Jorr-El]

Here are the two different versions of the same VI. What you see in the array constants is everything that's in the array constants - just one element initialized each.

I think altenbach's question about the iteration terminal illuminated the real issue actually, when I wired up an indicator and let both run until LabVIEW ran out of memory, the second one, which was growing memory more slowly, actually reached a smaller number of iterations than the first one (536 instead of 1610). So it appears that each loop was just taking far longer on the second version of the code, and the memory allocation WAS worse.

Debugging was also enabled on the VI, after I turned debugging off, the second version of the code ran out of memory much more quickly as well, matching what altenbach suggested as to the code attached to the uninitialized shift register getting thrown out as dead code by the compiler.