topic Re: How is array memory allocated? Stack Overflow! in Intel® Fortran Compiler

How is array memory allocated? Stack Overflow!

dwreich — Thu, 08 Aug 2002 07:33:59 GMT

How does Visual Fortran allocate memory for arrays? I'm trying to picture what's going on inside the computer to cause a stack overflow. We're having a debate here centered around the simple test program below. What's the difference between the calling argument being allocated in the calling routine and sent in and the local variables?

We seem to have fixed our problem by changing the local variables from using the dimension passed in to using a constant. What is the compiler doing different?

We'd like to let the calling routine take care of the dimension.

subroutine foo(x, n)
parameter (max=20)
c *** y & z are local variables ***
dimension x(n), y(n), z(max)

I'm using Visual Fortran v6.6a on W2K with 1Gb of RAM. I tried /stack:4000000 with no luck.

The real program we're debugging is a java client with a Corba server calling a C++/Fortran DLL via JNI which is making debugging a real pain.

Re: How is array memory allocated? Stack Overflow!

durisinm — Thu, 08 Aug 2002 20:01:58 GMT

It looks like you're trying to do dynamic allocation of arrays x and y. Try declaring x and y as ALLOCATABLE and then use the ALLOCATE statement with n as the dimension size.

Mike

Re: How is array memory allocated? Stack Overflow!

Steven_L_Intel1 — Thu, 08 Aug 2002 20:37:11 GMT

In your example, y and z are, as you say, local variables. z isn't relevant to the discussion, but y has its bounds determined at run-time by the dummy argument n. This makes it an "automatic array" and CVF allocates these on the stack when the routine is entered. Windows has a fixed stack size, allocated by the linker, defaulting to 1MB.

As Mike suggests, a better alternative is to declare y as ALLOCATABLE. For example:

subroutine foo(x, n)
parameter (max=20)
c *** y & z are local variables ***
dimension x(n), z(max)
real, allocatable :: y(:)
...
allocate(y(n))

This will cause the allocation to be on the "heap", not subject to the stack limitation. y will be automatically deallocated when foo returns, or you can deallocate it explicitly.

Steve