Out of Memory In LabWindows/CVI 8.1. It appears to be in the link step ?

[John G]

I have a  LabWindows/CVI Project that is buildable.

If I add a single variable to it I get an "Out of Memory" Error in what appears to be the build step.

The work around is to set the build option  "Options / Build Options / Debug Level'"  to "No Run-time Checking",

If I do this the project will build and execute.

Unfortunately I want the Run-time checking feature and I regard this as a temporary fix. What is the correct way to fix this build problem and allow me to have a Debug :Level of "Standard"

Thanks

[Jervin Justin]

Hi John,

Unfortunately without more information it is going to be pretty hard to reproduce and troubleshoot your issue.

Probably the best bet would be to post a copy of your code and we can take a look at it.

When you say you add a variable that breaks the build, do you simply declare one, or assign one? What kind of variable is it? What else is going on in your application?

Also, are you compiling a dll or an executable?

Have you tried compiling the program on a different system?

In task manager (Ctrl+Shift+Esc), do you notice a memory usage spike in the Performance tab?

As opposed to No run-time checking, try increasing the Uninitialized local variable detection to Aggressive.

These are all very basic troubleshooting questions that quite frankly are shots in the dark without more information.

[John G]

Basically :

   1) On my XP box I am using LabWindows/CVS Version 8.1.0    2) The application is an executable with an additional timer thread.    3) The statement is a single declaration which is unreferenced in the code :             double vx_array [2];    4) I set a breakpoint at the 1st executable line in the program ( after the main () ) and I never get to that
       statement so the program is not executing.

   5) Without the statement in 3) the Peak Memory Usage, as per the XP Task Mamager is 420M. With
       statement 3) in it goes to 2.1G. This value is in excess of the physical memory available but there
       is plenty of disk space for virtual memory.

   6) If I have the statement in and I take it to my other computer (a Vista Box with 2G of Memory and
       LabWindows version 8.5) the project builds and runs successfully    7)  I have proceeded onward working on the project adding code. Now if I add the statement in 3) the
        project builds correctly under XP. It beats me. I am tempted to assume that the problem has been fixed but these intermittant problems
have a tendency to return and not really go away.

Thanks

[Trevor]

I am having the same problem starting today with CVI 8.5.1. The project builds fine in release mode. In debug mode, with either "Standard" debugging level selected OR "Aggressive" unitialized local variables detection selected the link step fails with an out of memory error.

If I  set uninitialized local variables detection to "Conservative" and set the debugging level to "No run-time checking" the entire debug project can be linked.

I'm running on a Vista Box with 2G of Memory.

Is there more information about this problem?

Thanks,

Trevor

[Jervin Justin]

Hi Trevor,

I personally have not run into this issue, and would love to be able to reproduce it on my end, that way we might be able to get to the bottom of this...

I will need more information though in order to reproduce it.

Would it be possible for you to send us your code?

And is your situation like John's where he was able to narrow it down to one line of code, a declaration, that made the problem show up? If so, what does the line do?

Does it happen with any project or just this one? If it is just this one, On the same machine, what happens if you create a brand new project and add your code files to it? Does it still cause the behavior? 

Finally, are you able to reproduce this behaviour on multiple machines?  

Thanks, 

[CviUser2003]

Hello.  I don't know if this problem has been duplicated and solved.

But I'm having the same problem, that occurs both on my desktop computer (WinXP 1G ram) and laptop (WinXP 512M ram), both running CVI 8.5.1.

- I also saw the memory spike during link.  Before compile/link (under DEBUG only), Task Manager states the memory usage by CVI.EXE was at 51,100.  When I ran the link (compiling just one file), it spiked up to 537,016 before the "Out of Memory" appeared, and sometims has an "Internal eror" message, before closing CVI.  Sometimes my code is recoverable (it actually asks that I modified the file correctly, and asks for me to save it), but it exits out.

I had this error in earlier version of my code, under CVI 6 (which had the stack problem), but that older version compiled fine under CVI8.5.1 after I upgraded.  After adding code now (a year later) it creeped up again.  I tried to increase the stack size from 250,000 to 500,000 (and re-built my entire project from clean), but it didn't help - same problem of "Out of Memory" occurred.

In my case, the code was fine in my code revision 396.  But after adding the function, the "Out-of-memory error occurs:

void func(int b)

{

     if (panel_handle)

          SetCtrlVal( panel_handle, PANEL_CTRL, b );

}

I added a new variable, and it compiled/linked fine.

     static int iii=0;

However, I changed that to global scope, and I got the "Out of memory" error:

     int iii=0;

Is there a limit on how many global variables, or variable/function names on the debugger?  How can this be increased?

Unfortunately, I cannot send you the code either... 

[Eric_B.]

Hi,

I spoke with jjustin and he said that he was not able to reproduce that error either time it was reported.  The error message indicates that there is no more available memory on the stack, which is why when you define your variable as "static", it works just fine.  Declaring a variable as "static" means that the memory is allocated from the heap rather than the stack.

I know you increased your stack to 500K, but have you tried upping it to the maximum 1M?  Another thing to try changing in the Build Options menu is unchecking "Detect uninitialized local variables at run time".

Also, do you have access to CVI 9.0.1?  The release notes for 9.0.1 indicate that a bug involving an Out of Memory error was fixed, so that may or may not help out with your problem.  Also, CVI 9.0.1 includes a new feature, Resource Tracking, that has the ability to monitor your memory, so you could use that to see if there is a memory leak in your code.  An example of that feature can be seen here: http://zone.ni.com/devzone/cda/tut/p/id/7959

[Trevor]

I cannot find my notes on this issue but my recollection is that this became a 'known' and 'tracked' bug in the linker for CVI. It may be fixed in a newer version.

This was replicated by an NI Engineer (via telephone support) using my complete source code.

The problem was a 'special case' issue when some output of the linker had a very specific size and caused a memory error. The solution/work around was to create another variable with global scope (that isn't used by the application) that changes the size of the output and bypasses the bug.

I don't know why the NI Engineer who worked with me on the solution didn't file a KB article on this. I apologize for not updating this post sooner. Hopefully you haven't lost too much time on your project.

Regards,

Trevor Cooper 

[CviUser2003]

Unfortunately, increasing stack to 1M still gave me the same error.

I "hacked" the solution, by separating some global functions to external DLL's, so the global functions and global variables (that did not need to be global) was hidden from global scope.  I was going to move other functions/variables to static/file scope, but the DLL hack seems to work for now.

I think this DLL solution is temporary - there still "seems" to have a limited space and/or quantity for global scope names (variables or functions). 

[Mert_A.]

A couple people have run into this problem. I'd take a look at this thread -- it describes Torsten.Marx's experience with it and links back to Trevor's original post. The problem was fixed in CVI 9.0, but if you're using 8.5, you'll have to add a few extra global identifiers.

Mert A.

National Instruments