Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
New Contributor I
2 Views

parameters as actual argument cause stack overflow

Jump to solution

My old project goes wrong with Intel® Parallel Studio XE 2017 Update 4 again.

In sample code, subroutine foo crash on debug mode. (Stack overflow)

If change integer :: a(N) to a(1000000), the code goes well.

Similar things was happened with character parameter argument also.

 

    program Console2

        call foo(1000000)
    
    end program Console2
    
    subroutine foo(N)

    implicit none
    
    integer :: N
    
        integer:: a(N)
    
    end subroutine

 

0 Kudos

Accepted Solutions
Highlighted
Black Belt
2 Views

A local variable that is an

Jump to solution

A local variable that is an array that has a size that depends on a dummy argument (which is a form of automatic variable in Fortran terminology) is often stored on the stack - as its size may vary each time the procedure is called.

By default, the stack on Windows is only about one megabyte.  Your array requires about four megabytes.  Four megabytes does not fit in one megabyte.

You either need to:

- increase the stack size (in the Visual Studio properties for the executable, this is under Linker > System > Stack Reserve Size)

- tell the compiler that temporary arrays should be stored on the heap (in Visual Studio this is under Fortran > Optimization > Heap Arrays, set it to zero).

When you make the array size a constant, the compiler can set aside "static" storage for the array (i.e. not on the stack), as the storage required for the array is known at compile time.

View solution in original post

0 Kudos
10 Replies
Highlighted
Valued Contributor II
2 Views

Do you have the option for

Jump to solution

Do you have the option for debugging parameters on? (/debug-parameters:used or all). This has been the cause for similar crashes for me. It has been discussed before in this forum.

In Visual Studio the Debugging set of options

 

0 Kudos
Highlighted
New Contributor I
2 Views

I have posted complier error

Jump to solution

I have posted complier error by 'Information for PARAMETER Constants' set to All.

For this one, it doesn't matter.

0 Kudos
Highlighted
Valued Contributor II
2 Views

Oops, I should have mentioned

Jump to solution

Oops, I should have mentioned that you should set the value to "none". You cannot inspect the parameters then, but a crash is not very helpful either.

0 Kudos
Highlighted
New Contributor I
2 Views

I mean , setting 'Information

Jump to solution

I mean , setting 'Information for PARAMETER Constants' to none, doesn't help in this case.

It will still crash. 

0 Kudos
Highlighted
Valued Contributor II
2 Views

Then, I am afraid, I have no

Jump to solution

Then, I am afraid, I have no idea what is wrong.

0 Kudos
Highlighted
Black Belt
3 Views

A local variable that is an

Jump to solution

A local variable that is an array that has a size that depends on a dummy argument (which is a form of automatic variable in Fortran terminology) is often stored on the stack - as its size may vary each time the procedure is called.

By default, the stack on Windows is only about one megabyte.  Your array requires about four megabytes.  Four megabytes does not fit in one megabyte.

You either need to:

- increase the stack size (in the Visual Studio properties for the executable, this is under Linker > System > Stack Reserve Size)

- tell the compiler that temporary arrays should be stored on the heap (in Visual Studio this is under Fortran > Optimization > Heap Arrays, set it to zero).

When you make the array size a constant, the compiler can set aside "static" storage for the array (i.e. not on the stack), as the storage required for the array is known at compile time.

View solution in original post

0 Kudos
Highlighted
Valued Contributor II
2 Views

The error is because you

Jump to solution

The error is because you overflowed the stack. If you take a zero off the N value there is no overflow. That said is seems wrong to me to be using an arg to dimension a local  array that is not an arg. It would make more sense to allocate that local using the passed arg and you would have it on the heap rather than the stack.

 

0 Kudos
Highlighted
New Contributor I
2 Views

Thanks IanH!

Jump to solution

Thanks IanH!

Both suggestions are helpful!

I have modified  Stack Commit Size, it doesn't work. So I didn't change reserve size option, and posted the question here.

BTW, in older version of ivf, such as 2015/2012 i used before, setting stack commit size will aviod the stack overflow of the same code.

I don't know why?

0 Kudos
Highlighted
New Contributor I
2 Views

I am sorry, the question

Jump to solution

I am sorry, the question posted here is invalid.

Increasing stack reseve size is OK. And increasing commit size is always useless in each version.

 

0 Kudos
Highlighted
New Contributor II
2 Views

Rather than using the stack

Jump to solution

Rather than using the stack for the "Automatic" array, you can use an ALLOCATE array, which will go on the heap, then not need selection of any special compile options. This would be a more robust approach, eg:

program Console2

    call foo(1000000)

end program Console2

subroutine foo(N)

  implicit none
  integer :: N

  integer, ALLOCATABLE :: a(:)

!  executable statements
  ALLOCATE ( A(N) )
 

end subroutine

 

Note that ALLOCATE is an executable statement, not a declaration.
N can be much larger, say 100 million, or 1 billion in 64-bit environment.
You should review the documentation of ALLOCATE arrays, as they offer a number of advantages, but you need to consider the scope of the array.

0 Kudos