Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

STATUS_STACK_BUFFER_OVERRUN encountered

Kreienkamp__Frank
1,849 Views

Hello,

After a break of several years i am back again to use IVF. I am working on an old (converted) CVF  quickwin project consisting approx. 50 fortran-files. The program compiles in debug and release (both win32) mode without any warning and error. When I start the program it stops immediately with the message:

STATUS_STACK_BUFFER_OVERRUN encountered

No more. Unfortunately I have no idea where to search for the problem. Ideas will be appreciated. I havened found an idea based on an search in the forum.

I am using: Intel® Parallel Studio XE 2018 Update 1 Composer Edition for Fortran Windows* Integration for Microsoft Visual Studio* 2015, Version 18.0.0037.14,

Thanks in advance

Frank

 

0 Kudos
10 Replies
Lorri_M_Intel
Employee
1,849 Views

I have a couple of suggestions for things to look at.

First, when you converted your old program from CVF to Intel Fortran, the converter will add /iface:cvf by default to the command line.

However, any callback routines used by some of the QuickWin routines MUST be declared with default calling sequence, not 'cvf-compatible' calling sequence.

To find your callback routines, I'd check your usage of APPENDMENUQQ, MODIFYMENUROUTINEQQ, INSERTMENUQQ, maybe some others?  Those were the ones I found in the online help just looking for a few minutes.    Once you find your callback routines, you can add

!DEC$ ATTRIBUTES DEFAULT :: routinename

just after the routine declaration.

Of course -- you can remove the /iface:cvf that was added by the converter; you really only need that if you have existing/unchanged libraries that you need to call.

                        --Lorri

0 Kudos
andrew_4619
Honored Contributor II
1,849 Views

"without any warning and error." There are many warnings e.g. check interfaces  that are not on as standard. I would consider the check-all options.

0 Kudos
Kreienkamp__Frank
1,849 Views

Hello Andrew_4619,

I have already activated the check-all option. Unfortunately no warnings  present.

Frank

0 Kudos
Kreienkamp__Frank
1,849 Views

Hello Lorri,

I havened found the line /iface:cvf in my files. I think the person which has done the convert from CVF back in 2012 already removed this line.

We do not add libraries. It is all pure Fortran with just a tiny bit of quickwin.

We have not used APPENDMENUQQ, MODIFYMENUROUTINEQQ, INSERTMENUQQ in the code. We have used GETHWNDQQ, GETWSIZEQQ, MESSAGEBOXQQ, SETWSIZEQQ, GETDRIVEDIRQQ and CHANGEDIRQQ. Do I have to declare interfaces for those?

It is 'USE DFLIB' inside to code. Should I change it to 'USE IFLIB'?

Frank

0 Kudos
andrew_4619
Honored Contributor II
1,850 Views
The error I think is corrupting the stack, a common cause is writing past the end of s character string. If you have a break point set at the first line of your code do you get there in the debugger? If so just step line by line to find the crash.
0 Kudos
Lorri_M_Intel
Employee
1,850 Views

No, you don't need to change USE DFLIB; that mod file 'use's the correct, other mod files, including the one that defines the entry points for the QuickWin routines.

Please try Andrew's suggestion to start at the beginning of your program, and see if you can find the crash.

 

 

 

0 Kudos
Kreienkamp__Frank
1,850 Views

Hello,

unfortunately Andrews way is not working. The error occurs before the first line with an possible break point.

May includes like INCLUDE 'limits.inc'(for variables) , INCLUDE 'actual.cmn' (for common blocks) including definitions of variables and common block can cause the problem? Those lines (actually 20 includes) are placed before and inside the variable definition.

as example (incomplete lines) :

C **********************************************************************
IMPLICIT NONE

C specifications:
INCLUDE 'limits.inc'

C ********************* list of common blocks **************************
C a) actual field limits
INCLUDE 'actual.cmn'

C * local fields
REAL vgsave(N1MAX) , wfsave(N1MAX) , bfdsave(N1MAX)

C c) additional blocks of 3d model
C * general parameters, grid structure
INCLUDE 'geom.cmn'

C ***************************** Local variables ************************
REAL ath(0:NXMAX,0:NYMAX,NZMAX) , fluxx(NXMAX)
REAL CC(NXMAX,NYMAX,NZMAX) , CC1(NXMAX,NYMAX,NZMAX) 
C ********************** Equivalent fields *****************************
EQUIVALENCE (ath,dd)
REAL DTDpsi2m(NXMAX,NYMAX,NZMAX) 

 

 

Frank

 

0 Kudos
John_Campbell
New Contributor II
1,850 Views

Your problem could be large local arrays, potentially like "ath", "CC" and "CC1" which may have been static allocation in 2012. They could now be overflowing the available stack. These might be solved by:
* increasing the stack size, or
* moving these arrays from the stack to heap ( see recent posts), or
* make them static by moving them to a module or COMMON, or
* making them allocatable
* use compile options to change dynamic arrays to static/saved

The first step should be to identify these large local arrays and determine if they could be causing the problem.
my preference is use ALLOCATE as it identifies your action to move large local arrays.

0 Kudos
Kreienkamp__Frank
1,850 Views

Good mooring John,

Thanks.

Most big arrays are dimensioned by numbers out of an include file. I have reduced those numbers to small values. No change. I have also changed the Configuration Properties - Linker - System - Heap Reserve Size and Stack reserve size the large values. No change.

Unfortunately must arrays are used in equivalence statements.

I looks like an large rewrite before I can use allocatable arrays.

Frank

 

 

 

0 Kudos
Dastous__Jean-Bernar
1,849 Views

I had the same error with a simple fortran code that I moved recently into a new solution in Intel® Parallel Studio XE 2017 Update 4 Composer Edition for Fortran Windows* Integration for Microsoft Visual Studio* 2012, Version 17.0.0047.11. This program had allocatble arrays in it.

The same program worked fine before. After a few hours of trying to find the issue, I simply recreated a new solution with the same fortran source code in a different folder on my computer (Under Windows 7) - the error disappeared and the program worked as before. I don't understand why - seems like a bug ? So if you get this error, maybe try what I did.

0 Kudos
Reply