Insufficient Vitural Memory XE Composer 2013

Insufficient Vitural Memory XE Composer 2013

I am using Intel Studio XE 2013 with Visual Studio Ultimate 2010. I am compiling a big project. I've got some problems.

1. I am choosing X64 to run compliler. It's done, however the "stack oveflow" occured. I followed Steve's recommendation to modify "heap array=0". then, It work.

2. I've got another trouble, the program run well untill several seconds ( 200 steps, each step is 0.1s) and it stopped because of "insufficient virtural memeory". I run this program on C:\ directory, so, I modified virtural memory in C:\ from "automatic" to setting up 40GB (40000MB). It is ok, but, the program run until 600steps and then it stop. I think this is the problem from compiler or IDE.

Could you please help me to solve this problem.

Thank you in advance!

Franck

publicaciones de 4 / 0 nuevos
Último envío
Para obtener más información sobre las optimizaciones del compilador, consulte el aviso sobre la optimización.

I used window 7 64 bit

Imagen de John B. Walter

Sounds like your code is using more memory the more itterations it executes. If it shouldn't, then the problem could be that you have a memory leak in your code; inside the itteration it is allocating memory and not releasing it when it is done. Another possibility is that a variable specifying the amount of memory to allocate is not being properly set. It's likely some bug in your code that it is trying to use so much memory, or a problem in your design if it actually needs that much.

I'd run task manager and select as many memory stats as possible to see if this confirms the memory leakage problem.
Does your project utilise large allocatable arrays or large allocatable pointer arrays, as leakage is typically associated with not releasing memory for allocatable pointers when they are re-targeted.
Certainly there can be memory leakage problems with large allocatable pointer arrays. These have been discussed on the forum during 2012 and their handling in the compiler might have changed.
Conventional allocatable arrays should be more robust, as the standard requires auto deallocate of local allocatable arrays, although this does not apply to allocatable arrays in modules.
I am also puzzled by the stack problem, as this would indicate local or automatic arrays. My understanding is that allocatable arrays do not use the stack, so a stack error should imply local arrays that are not allocatable. You might have to investigate them also. Typically you make large arrays allocatable, so that if you have local arrays overflowing the stack, then the problem could be with the automatic array dimension not being correctly defined.

New compilers often expose old bugs.

John

Inicie sesión para dejar un comentario.