Re: Help: IFC stack overflow

Ben wrote:
Hi,

I have a module with many global arrays,

!------------------------------------------------------
module Global
integer, save :: dims(4)=(/0,0,0,0/)
real (kind = 8), save, allocatable :: A(:,:,:,:)
! save data read from a file
real (kind = 8), save, allocatable :: B(:,:,:,:) ! B to E
have the same size
real (kind = 8), save, allocatable :: C(:,:,:,:) ! as A
real (kind = 8), save, allocatable :: D(:,:,:,:)
real (kind = 8), save, allocatable :: E(:,:,:,:)
. . .
. . .
. . .
logical, save, allocatable :: L(:,:,:,:)

contains
!
! subroutines here
!
end module Global
!--------------------------------------------------------

When I read in the dimensional information to dims, these arrays can
be allocated.

The process is
* read in dimensions
* allocate A, populate A using file stream I/O
* allocate B, save intermediate results in B (e.g. sub1(B,A))
* allocate C, do something like sub2(C,B)
etc

Everything works fine when I compile the codes with g95.

However, when I tried to use Intel Fortran compiler 9, it only works
when the data size is relatively small, say dims= (/30,30,8,30/). For
large dimensions like dims=(/256,256,25,30/), it crashes when I call
sub3 to allocate D array. The error report is stack overflow:

forrtl: severe (170): Program Exception - stack overflow
( I have not found the error code 'severe (170)' in Intel docs)

The computer has plenty of memory (4GB). I also check the status
after each allocate statement.

I am wondering why the data size matters.
Is it related to the 'save' attribute?
Will it be helpful if I reduce the number of those global arrays?

Any suggestions and comments are welcome.

Thanks.

Ben


Some array operations use a lot of stack space when it is necessary to create a temporary array. Array allocations should not need much stack space, but it is not unusual for a default stack limit to be rather small. Assuming a POSIX environment, what do you get from the command "limit stack"? You can try a larger number, or just try "limit stack unlimited".

As for the SAVE attributes, they probably have no effect, but it is a good practice. It is possible (but unlikely) for values to become undefined if a module is not USEed from the main program.

Joe
.

Relevant Pages

  • Re: performance question related to BST traversal
    ... Suppose I have to traverse the BST by Preorder, say, without using ... Suppose I use a stack ... Instead of an array of nodes, I use a singly linked list. ... allocate an array of nodes and link them into a free list. ...
    (comp.lang.c)
  • Re: Stack or Heap
    ... that often allocated on the stack. ... on an array then the compiler *might* attempt to allocate a temporary ... array result off of the stack to hold the result. ... is no such protection for C programmers using gcc. ...
    (comp.lang.fortran)
  • Re: On VLAs and incomplete types
    ... from a stack. ... The real advantage, though, comes with code like your 2D array ... allocate and deallocate memory, so there must be an explanation for ... The generation of dynamic memory is more complicated and requires ...
    (comp.lang.c)
  • Re: Stack or Heap
    ... are allocated on the stack whereas allocated variables ... that often allocated on the stack. ... on an array then the compiler *might* attempt to allocate a temporary ... array result off of the stack to hold the result. ...
    (comp.lang.fortran)
  • Re: Cons cell archaic!?
    ... from s-expression or XML or other syntax you keep the bloated array ... For using vectors to emulate lists that ... Allocate 2, move 1 element: ... What do you think of that algorithm? ...
    (comp.lang.lisp)