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: 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: allocating arrays, trouble
    ... array and memory? ... Comment: Using GnuPG with SUSE -http://enigmail.mozdev.org ... Explicitly allocate the arrays you need at the start. ... One of these concerns the use of the stack. ...
    (comp.lang.fortran)
  • Re: static, global variable memory allocation
    ... You reserve a special array somewhere, ... initialize a pointer to point to one end of it, ... preferred implementation for stack. ... There could also be a mixed-mode strategy: Allocate a small ...
    (comp.lang.c)
  • Storing/Retrieving TYPEs with ALLOCATABLE components (TR) (long)
    ... tBrd, including array descriptor of tEn )). ... Without previous DEALLOCATE, the allocate line fails at run time with message ... the fact that I'm loading an invalid descriptor tBrd%tEn from the file... ... status (which is not possible according to Standard, but then BINARY files ...
    (comp.lang.fortran)