I have a simulation software that I am part of the development which runs a variety of different model inputs. For one of the model inputs triggers a stackoverflow crash that only occurs in debug mode. Below is what is printed to the command prompt and I have attached an image of what pops up when I run debug within VS. (I apologize for deleting the information pertaining the specific files.)
######################################################
forrtl: severe (170): Program Exception - stack overflow
Image PC Routine Line Source
PROG_Debug 0000000141A3CB77
PROG_Debug 00000001405ED7D0
PROG_Debug 00000001400C4C4A
PROG_Debug 0000000141815D36
PROG_Debug 0000000141ABA386 Unknown Unknown Unknown
PROG_Debug 0000000141A3D1FC Unknown Unknown Unknown
PROG_Debug 0000000141A3D33E Unknown Unknown Unknown
kernel32.dll 00000000770959ED Unknown Unknown Unknown
ntdll.dll 00000000771CC541 Unknown Unknown Unknown
######################################################
Looking at the line numbers for the code it crashes on the following FORALL statement
FORALL(I=1:NROW,J=1:NCOL,K=1:NLAY,ILOC(J,I,K).NE.0) + BUFF(J,I,K)=BUFF(J,I,K)/( DR(J)*DC(I)*(BTM(J,I,LM(K)-1)-BTM(J,I,LM(K))) )
(Note that in this run NROW=150, NCOL=150, NLAY=6, so they are not big arrays and the LM index pointer array is correct)
The indexing is fine and all the variables are fine (used in other parts of the code). When I run the code on release it does not crash, but the variable BUFF is dumped to a file after that FORALL, but that happens as if the FORALL acts like a RETURN statement.
When I change the FORALL to a DO CONCURRENT as follows:
DO CONCURRENT (I=1:NROW,J=1:NCOL,K=1:NLAY,ILOC(J,I,K).NE.0) BUFF(J,I,K)=BUFF(J,I,K)/( DR(J)*DC(I)*(BTM(J,I,LM(K)-1)-BTM(J,I,LM(K))) ) END DO
The code in debug mode behaves as expected. Is this a bug, or am I missing something with regards to FORALL statements. Should I go through my code and clean out the FORALL in favor of DO CONCURRENT.
Thanks as always.