Unexplainable MEMORY FULL error in 8.2

[CoastalMaineBird]

Alright, I finally got my client to take a look at LV 8.2 (we've been on LV 7.0 for 3 years).

So I have it running in Evaluation mode (we haven't purchased it yet).

I'm running in WinXP Pro/SP2 under Virtual PC 7.0 on a 2x2GHz G5 Power Mac.

The program works perfectly on LV 7, on a real Win2000 box, and on this Virtual PC setup.

The first time I try to run one of my programs in LV 8.2, I get this MEMORY FULL error.

It complains about the INITIALIZE ARRAY function. Notice that it's wired to the #SAMPLES control which is set to the highest I32 value possible (as a default condition). You might think that that's it - I'm trying to allocate 2+ gig of samples, and it just can't do it.

Here's the kicker:

The break point at INITIALIZE ARRAY did NOT get hit.

The break point at the CASE ouside of that did NOT get hit.

A break point at the CASE outside of that (not shown in this pic) did NOT get hit.

The FUNCTION control on the front panel is NOT set to INIT, but to "ShutDown", which SHOULD cause a different case to be executed.

A breakpoint at the parent's call to this VI DID get hit. But if I step IN from there, the first step stops at the WHILE loop, the next step hits the error.

This VI is not re-entrant, or any other weird setting.

In other words, it appears to be executing the wrong case.

This is my first try on LV 8.x, so maybe I'm missing something. Is it trying to be "helpful" and warn me about what it thinks are future problems?

Why is it executing the wrong case?

---

Message Edited by CoastalMaineBird on 11-16-2006 07:16 PM

[Darren]

Why don't you try running the VI with execution highlighting, which should show you exactly which node is causing the error.

Also, do you have the VI Analyzer?  If so, you could try running it over this VI to see if you have any hidden wires, constants, or functions on the diagram that aren't easily visible.

Any chance you could post the code, or a pared-down version that demonstrates the problem, for further investigation?

-D

[CoastalMaineBird]

I did the single-stepping with execution highlighting ON, and it steps as I described above.

If I PROBE the FUNCTION wire between the terminal and the WHILE loop, it is SHUTDOWN (as it should be).

If I probe it INSIDE the WHILE loop, it stays dimmed (never gets updated).

If I wire a ZERO to the #SAMPLES terminal at the CALL to this VI (in the parent), then it executes the SHUTDOWN case, as it should.

If I remove that constant, then it again steps into the INIT case, bypassing breakpoints and probes.

But the #SAMPLES terminal should be ignored in the SHUTDOWN case, which is why I left it unwired.

I can't post the whole code, but I'll try for a simpler demo case.

[Darren]

Ok, I hope you're able to post a VI that demonstrates the problem, because I can't see any reason why you would see this behavior based on the description and screenshot you provided.  My previous suggestion still stands...it would be beneficial to run the VI Analyzer on this code, just to make sure there aren't any hidden wires, constants, functions, etc. that could be causing the problem.

-D

[tst]

In the same spirit as Darren's suggestion - the message says that the VI stops at the initialize array function. Did you try searching to find all the occurences of the function to make sure that there isn't one where you don't expect it?

I suspect that maybe you have a constant folded array initialized somewhere and it might be initialized even without you running the case where it is located.

[CoastalMaineBird]

Did you try searching to find all the occurences of the function to make sure that there isn't one where you don't expect it?

No, but when I dismiss the error dialog, I get a focus drawing (the shrinking rectangle) which leads me to the particular instance in the picture (the one with the breakpoint).

In other words LabVIEW is drawing my attention to this particular one.

[Ben]

I have to go with tst's idea that this is "constant folding".

I have not been able to allocate more than 1.2 G in a single array.

Ben

[CoastalMaineBird]

I have to go with tst's idea that this is "constant folding".

I don't know what you mean by that term.

I have not been able to allocate more than 1.2 G in a single array.

I am not trying to. My point is that the INIT ARRAY function should not be called - the VI is given a function of SHUTDOWN, and the SHUTDOWN case does not allocate anything, nor even use the # SAMPLES terminal.

Yet if I wire it to 0, the correct case is executed.

[Ben]

Hi Coastal,

See this thrad for starters on constant folding.

http://forums.ni.com/ni/board/message?board.id=170&message.id=207197&query.id=431152#M207197

I believe constant folding happens before the VI runs.

Ben

[CoastalMaineBird]

Alright - here's the bug - the stupidest thing I've ever seen from LabVIEW.

This library is in LV 7.0 - it works perfectly in LabVIEW 7.

But in LabVIEw 8.2, in SPITE of the fact that I call it with a function of SHUTDOWN, it insists on complaining about the code that I DON'T EXECUTE.

Run the BUG CALLER and see for yourself.