Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

stack/heap and memory leaks

Rob1
Beginner
2,411 Views

Hi,

Recently large data sets were causing stack overflows in a program of mine.  To allow for larger temporary arrays (prevent stack overflows), I changed Fortran>Optimization>Heap Arrays from <blank> to 0 (see attached memsetting.jpg).

After this change my program was using up all available memory to the point where ALLOCATE would fail.  Also i was able to see the memory used up in task manager.

.

I built a test program to verify what i was seeing:

PROGRAM mainprog
IMPLICIT NONE

REAL*8, ALLOCATABLE, DIMENSION(:) :: allocarray

ALLOCATE(allocarray(10))


CALL memsub(SIZE(allocarray),allocarray)
WRITE(*,*) 'allocarray',allocarray
DEALLOCATE(allocarray)


ENDPROGRAM mainprog

.

SUBROUTINE memsub(n,array)
IMPLICIT NONE

INTEGER, INTENT(in) :: n
REAL*8, INTENT(inout), DIMENSION(n) :: array

REAL*8, DIMENSION(n) :: localarray
INTEGER i


localarray = 1.D0
DO i = 1,n
array(i) = -DBLE(i)
ENDDO
array = array + localarray


ENDSUBROUTINE memsub

.

.

If i set "Heap Arrays" to blank, Inspector does not detect any problems.

.

If i set "Heap Arrays" to 0, Inspector detects a memory leak:

ID Problem Sources Modules Object Size State
P1 Memory leak memsub.f90 memtest.exe 80 New

.

If i set "Heap Arrays" to 0, and change my local variable "localarray" to allocatable (and deallocate it at the end of the subroutine), Inspector does not detect any problems.

.

The Inspector results agree with what i was seeing in my program as far as memory usage.

My conclustion is that explicitly declared temporary arrays (not sure if that is the correct term, for example: REAL*8, DIMENSION(n) :: localarray) do not get automatically freed when they are created on the heap like i assumed they were.

Is this common knowledge?  I didn't pick this up from reading posts about stack vs heap.

I guess I will stop using "Heap Arrays = 0" and try increasing the stack size to hopefully cure my issues?  I have no idea what the stack size should be.  Is there a way to tell what the default stack size is?

thanks,

rob

0 Kudos
13 Replies
Lorri_M_Intel
Employee
2,411 Views
Yes, unfortunately you stumbled onto a bug. It is a known bug, the internal id is DPD200235943. And yes, it is specific to automatic arrays and the /heap-arrays option. --Lorri
0 Kudos
Rob1
Beginner
2,411 Views
Ok. I forgot to mention my version: Intel(R) Visual Fortran Composer XE 2013 Integration for Microsoft Visual Studio* 2008, 13.0.3588.2008, Copyright (C) 2002-2012 Intel Corporation . Is this bug specific to this version? What is the most recent version without this bug? . Can anyone suggest a workaround for this? . thanks, rob
0 Kudos
Steven_L_Intel1
Employee
2,411 Views
This problem was just reported to us a week ago. As you have the latest version, it still has the bug. The bug hasn't been fixed yet. When it is, we'll update this thread. By the way, the version you report is the VS integration, not the compiler, but there's only one 13.0 to date so it didn't matter.
0 Kudos
John_Campbell
New Contributor II
2,411 Views
As a work around, you could change the automatic array to an allocatable array. I would expect that this should not impact on the stack or heap. eg: SUBROUTINE memsub(n,array) IMPLICIT NONE INTEGER, INTENT(in) :: n REAL*8, INTENT(inout), DIMENSION(n) :: array REAL*8, DIMENSION(:), allocatable :: localarray INTEGER i ! allocate (localarray(n)) ! localarray = 1.D0 DO i = 1,n array(i) = -DBLE(i) ENDDO array = array + localarray ENDSUBROUTINE memsub John
0 Kudos
Rob1
Beginner
2,411 Views
Thanks for the responses everyone. . Steve, so is 13.0 the only version with this bug? Does this bug also exist in 2011 update12? . John, yes i tried this method and it did seem to "fix the glitch", however i would need to change a lot of code in a lot of different files as my program is fairly big. I'd rather install a different version of the compiler that didn't have the bug. Also in your code example, would you want to deallocate localarray at the end of the subroutine? In my tests i deallocated and didn't have any memory leaks. Or is the deallocation done automatically now? . thanks, rob
0 Kudos
Rob1
Beginner
2,411 Views
I am in a rush to get my code working again. Can someone please answer if this bug exists in 2011 update 12? Also it would be good to know how to determine what the default stack size is. thanks, rob
0 Kudos
John_Campbell
New Contributor II
2,411 Views
Rob, I can't answer your question about the bug, but if you are chasing stack and heap overflow then I’d strongly recommend that you change automatic arrays to ALLOCATE. This should fix your problem. Minimising the use of local stack arrays in this way is a much easier and quicker approach, otherwise stack overflow will be with you for a long time. For allocatable arrays, deallocate is automatic, but would be neater to include. John
0 Kudos
Johannes_Rieke
New Contributor III
2,411 Views
Hi Rob, corresponding to http://software.intel.com/en-us/articles/intel-composer-xe-2011-compilers-fixes-list bug DPD200235943 is not solved in 2011 update 12. @intel These fix lists are hard to find. Maybe it's possible to give a link to them on the corresponding release note page or put them in a sticky thread in the forum along with the release notes? Kind regards, Johannes
0 Kudos
Rob1
Beginner
2,411 Views
Thanks again for the help guys. John, this is what i'll be doing from now on, thanks. rob
0 Kudos
Steven_L_Intel1
Employee
2,411 Views
I will include a link to this article in various places - thanks for the suggestion.
0 Kudos
Steven_L_Intel1
Employee
2,411 Views

This problem was fixed in a 13.0 update.

0 Kudos
Rob1
Beginner
2,411 Views

Which update?

Does 2013.5.198 have the fix?

thanks,

rob

0 Kudos
Steven_L_Intel1
Employee
2,411 Views

Yes, it should. I would say it was fixed in update 2 or 3.

0 Kudos
Reply