allocate/deallocat stack question

[nvaneck]

I have some code where there are a series of allocate/deallocate calls that increase the size of an element of an array of arrays in a module. After it gets to allocate a large amount(about .5MB)I get stack overflow from moving the new array element arrayafter the last allocate to the old element slot. Does Fortran use the stack for this movement?

If I set the stack size to 4mb, the problem goes away.

Also, right now I allocate a new element array, move the data to it, deallocate the origninal element, allocate it to the new size, and move the saved element back. Can I use move_alloc on an allocated element of an array, and would this help?

[mecej4]

You did not give a specific example, so I have to be correspondingly vague.

I think that the use ALLOCATED variables is not an issue. In assignments, procedure calls (and other places, perhaps), the compiler may need to allocate a temporary variable. Such variables are allocated on the stack, but there is little that one can see in the source code that immediately says "stack consumption here". If one of these temporary variables is a large array or a large derived type variable, stack exhaustion can occur.

The problem would occur even if the declared variables were static (i.e., with the SAVE attribute) instead of being ALLOCATEd.

[Steven_L_Intel1]

Yes, by default the stack would be used if a copy of array elements is done. You could use MOVE_ALLOC to transfer the storage of the newly sized array back to the original array without copying the data, but not on a single element. I am not completely sure of what your code looks like - I would not expect a large stack copy to be needed in this case.

You can also use /heap-arrays to use dynamic storage for temporaries.

[nvaneck]

Thanks, it makes sense. the code has a allocated array, WFREQS, of allocated elements.

At the failing step WFREQS has two elements.

The first element has an allocated size ofof about 47000 real(8) locations.

The second element is not yet allocated.

The code then allocates WFREQS(2) at 62000. and copies WFREQS(1) to WFREQS(2).

Then it deallocates WFREQS(1) and reallocates it to the new 62000 elements.

The step fails in copying WFREQS(2) to WFREQS(1), so there is large move.

This code initial allocates the elements to a typical size to allow a 10 x 10 table. As it gets filled from user data, the elements are grown by 50% as indicated above.

This should never be a problem unless, as in this case, the user stupidly uses an ID variable on a large dataset (I.e., 130,000 records in this case).

The only way I can figure out hw to avoid this happening in light of the stack use is to arbitrairily cut off the number of cells at some reasonable value and fail the program with a message.

But is there any way to trap a stack overflow? Or a way to avoid using the stack?

Thanks again for the explanations.

[Steven_L_Intel1]

Set the project property Optimization > Heap Arrays to 0.

[nvaneck]

Thanks, Steve, That does it for me.

[BABAK]

Hi
In a very small program when I debug the program with the "Heap Array" being without a number or with number '0' there is no problem. But when in my large program which consists of subroutines with large-sized ARGUMENT arrays, when the "Heap Array" is blank I get an error about stack overflow. As I have read through other threads one way is to change the "Heap array " number to '0' to solve this problem. But when I do so my output would only be 'NaN'. I don't know how to solve this problem.

BUT when I run my large program without SUBROUTINES I do not get any error with stack overflow when the "Heap Array" is blank. But when I change the "heap array" to '0' I again get "NaN" .

How can I solve this problem?

Thanks