Debug vs Release Mode in Visual Studio

[rafadix08]

I am a bit confused since I ran my code on debug mode with no problem at all, but after I compiled it on release mode, the program crashed first with a stack overflow message and then (after I increased the stack size) with an access violation message.

I checked and both under the debug and release modes, the project properties were exactly the same.

Is this something common? And what can I do in order to debug it?

[Steven_L_Intel1]

It is unlikely the project properties were the same. Release mode enables optimization and disables a number of diagnostic checks.

You can start with a Debug configuration and raise the optimization level, but errors of this nature that show up with optimization are often caused by coding errors that violate language assumptions.

[TimP]

Diagnostics which may be useful include static checking: /Qdiag-enable:sc
and run time checking: /check /traceback

[rafadix08]

Here is what I have done:

I set all of the Project Properties>Fortran>Optimization options under the debug mode to be the same as in the release mode.

Optimization - Maximize Speed
Inline Function Expansion - Any Suitable
Favor Size or Speed - Favor Fast Code
etc...

The code still runs smoothly under debug mode. So, I was not able to reproduce the problem under debug mode.

I used the traceback option when the code is compiled under release and it tells me where the problem occurs... I put a lot of prints around the code and found that a certain variable mysteriously changes its value to zero. This occurs inside a code that is not mine and that I have never evertouched. It is written in F77 and I have extensively used it in the past with no problems.

I must say that the code compiled under release mode only crashes when I tell the compiler to generate parallel code (OpenMP). However, it is crashing in a spot where there is no parallelization going on.
Just to be clear, the program is crashing because a variable's value inside this other program I am usingis turning to zero out of the blue.

Any other hints where I could be looking at?

Is there maybe a F77 compatibility issue here?

Many thanks,
Rafael

[DavidWhite]

Quoting - rafadix08

Here is what I have done:

I set all of the Project Properties>Fortran>Optimization options under the debug mode to be the same as in the release mode.

Optimization - Maximize Speed
Inline Function Expansion - Any Suitable
Favor Size or Speed - Favor Fast Code
etc...

The code still runs smoothly under debug mode. So, I was not able to reproduce the problem under debug mode.

I used the traceback option when the code is compiled under release and it tells me where the problem occurs... I put a lot of prints around the code and found that a certain variable mysteriously changes its value to zero. This occurs inside a code that is not mine and that I have never evertouched. It is written in F77 and I have extensively used it in the past with no problems.

I must say that the code compiled under release mode only crashes when I tell the compiler to generate parallel code (OpenMP). However, it is crashing in a spot where there is no parallelization going on.
Just to be clear, the program is crashing because a variable's value inside this other program I am usingis turning to zero out of the blue.

Any other hints where I could be looking at?

Is there maybe a F77 compatibility issue here?

Many thanks,
Rafael

Rafael.

Suggest that you check all the arguments to your routines - correct type and array sizes in both the caller and the subroutine; also check similarly if you are using COMMON.

Appears that memory is being trampled on, perhaps due to array size mismatches. Note, for example, some older Fortran used Arrayargument(1) to represent a variable size array. These should be changed to Arrayargument(*).

Regards,


David

[rafadix08]

Quoting - David White

Rafael.

Suggest that you check all the arguments to your routines - correct type and array sizes in both the caller and the subroutine; also check similarly if you are using COMMON.

Appears that memory is being trampled on, perhaps due to array size mismatches. Note, for example, some older Fortran used Arrayargument(1) to represent a variable size array. These should be changed to Arrayargument(*).

Regards,


David

David,

Many thanks for the reply.
I will double check the the arguments, but this problem is only occuring when I "generate parallel code" with Openmp. I also removed the omp directives, so that I only have serial code. If I compile with openmp the crash still happens... If not, then it runs smoothly... for this reason I think it shouldn't be a mismatch problem. Am I wrong?

Looks like it's openmp related.

Many thanks again,
Rafael

[rafadix08]

I double checked everything.

I am still confused why in debug mode the code runs smoothly both serially andusing OpenMP, evenafter raising the optimization options, as Steve suggested.

When I compile with Release mode and generating a serial code, everything works. So, it seems unlikely to me that I have an error in my code. The problem occurs only when I compile the parallel code (OpenMP) under the Release mode. As I mentioned, the problem comes from some variable that becomes zero after a subroutine is called. There is no assignment to this variable and this is not a global variable.

I really appreciate any help... I've been stuck on this for three days now.

[Mark_Lewy]

Quoting - rafadix08

I double checked everything.

I am still confused why in debug mode the code runs smoothly both serially andusing OpenMP, evenafter raising the optimization options, as Steve suggested.

When I compile with Release mode and generating a serial code, everything works. So, it seems unlikely to me that I have an error in my code. The problem occurs only when I compile the parallel code (OpenMP) under the Release mode. As I mentioned, the problem comes from some variable that becomes zero after a subroutine is called. There is no assignment to this variable and this is not a global variable.

I really appreciate any help... I've been stuck on this for three days now.

Note that the openmp compiler option also sets the automatic option. You may have variables in your program that rely on being implicitly saved.

[Steven_L_Intel1]

You might download a free evaluation version of Intel Thread Checker and have it look at your program to see if there are threading errors. Even if the error appears in a serial region, it could be triggered by an error in a parallel region.

[rafadix08]

Quoting - Steve Lionel (Intel)

You might download a free evaluation version of Intel Thread Checker and have it look at your program to see if there are threading errors. Even if the error appears in a serial region, it could be triggered by an error in a parallel region.

Many thanks for the replies, but even if I write my code serially, that is, WITHOUT all the omp directives, and compile it with the openmp option, the code runs fine under debug mode but crashes under release mode.

If there was an error in a thread region why wasn't it triggered using the debug mode? What are the possible options that are activated (or deactivated) on debug that are different as in Release that might be causing this difference in behavior?

I already tried the Optimization options, and debug works fine and release crashes.

Thanks,
Rafael

[TimP · Accepted solution]

Quoting - rafadix08

Many thanks for the replies, but even if I write my code serially, that is, WITHOUT all the omp directives, and compile it with the openmp option, the code runs fine under debug mode but crashes under release mode.

If there was an error in a thread region why wasn't it triggered using the debug mode? What are the possible options that are activated (or deactivated) on debug that are different as in Release that might be causing this difference in behavior?

I already tried the Optimization options, and debug works fine and release crashes.

This looks very much in line with the suggestion Steve made, that (in effect) you are depending on SAVE behavior somewhere you didn't specify it. You didn't say whether /Qdiag-enable:sc was able to point out instances where this occurs.
Optimization frequently involves moving data updates around, or omitting them when your source code says they aren't needed. As Steve pointed out, /Qopenmp has to set /Qauto; as he didn't point out explicitly, the compiler isn't obligated to trip over bugs in debug mode unless you ask specifically to have them pointed out.

[rafadix08]

Quoting - tim18

This looks very much in line with the suggestion Steve made, that (in effect) you are depending on SAVE behavior somewhere you didn't specify it. You didn't say whether /Qdiag-enable:sc was able to point out instances where this occurs.
Optimization frequently involves moving data updates around, or omitting them when your source code says they aren't needed. As Steve pointed out, /Qopenmp has to set /Qauto; as he didn't point out explicitly, the compiler isn't obligated to trip over bugs in debug mode unless you ask specifically to have them pointed out.

Thank you all very much for all your comments.

I still wasn't able to make it work, although it seems to me that the problem relies on a Fortran 77 optimization code Iwas using. I am now using another optimization code and it's working well. The curious thing is thatuntil three days agothe original optimization code was performing just fine.

I did compile with /Qdiag-enable:sc but Ididnotaccuse any implicit saves on the code, or other major errors.

Best,
Rafael

[rafadix08]

Quoting - rafadix08

Thank you all very much for all your comments.

I still wasn't able to make it work, although it seems to me that the problem relies on a Fortran 77 optimization code Iwas using. I am now using another optimization code and it's working well. The curious thing is thatuntil three days agothe original optimization code was performing just fine.

I did compile with /Qdiag-enable:sc but Ididnotaccuse any implicit saves on the code, or other major errors.

Best,
Rafael

Here is a question that might be related to this problem:

I call an optimization routine (external code). The input is a vector of parameters called param
(real param(NPARAM))

call newuoa(...,param,...)

newuoa uses an assumed-size dummy array

the optimization routine newuoa in turn calls a function called calfun.f, where the user is supposed to define the function to be optimized.

Here is my definition:

SUBROUTINE CALFUN(N,X,F)

USE SMM_OBJ_FCN_MOD

IMPLICIT NONE

INTEGER N
REAL(KIND=DOUBLE) X(N)
REAL(KIND=DOUBLE) F

CALL SMM_OBJ_FCN(X,F)

RETURN
END


The subroutine SMM_OBJ_FCN is a subroutine defined by me in module SMM_OBJ_FCN_MOD and has interface:

Interface
Subroutine SMM_OBJ_FCN(ParamScaled,F)
real , intent(in) :: ParamScaled(:)
real , intent(out) :: F
end subroutine SMM_OBJ_FCN
end interface

That is, SMM_OBJ_FNC uses an assumed-shape dummy array. It must be the case because there is another subroutine that calls SMM_OBJ_FNC that requires that.

Is this mix between subroutines that use an assumed-shape and assumed-size arrays possibly causing my problem?

If yes, how could I deal with it, without changing the external codes?

Many thanks,
Rafael

[rafadix08]

Quoting - rafadix08

Here is a question that might be related to this problem:

I call an optimization routine (external code). The input is a vector of parameters called param
(real param(NPARAM))

call newuoa(...,param,...)

newuoa uses an assumed-size dummy array

the optimization routine newuoa in turn calls a function called calfun.f, where the user is supposed to define the function to be optimized.

Here is my definition:

SUBROUTINE CALFUN(N,X,F)

USE SMM_OBJ_FCN_MOD

IMPLICIT NONE

INTEGER N
REAL(KIND=DOUBLE) X(N)
REAL(KIND=DOUBLE) F

CALL SMM_OBJ_FCN(X,F)

RETURN
END


The subroutine SMM_OBJ_FCN is a subroutine defined by me in module SMM_OBJ_FCN_MOD and has interface:

Interface
Subroutine SMM_OBJ_FCN(ParamScaled,F)
real , intent(in) :: ParamScaled(:)
real , intent(out) :: F
end subroutine SMM_OBJ_FCN
end interface

That is, SMM_OBJ_FNC uses an assumed-shape dummy array. It must be the case because there is another subroutine that calls SMM_OBJ_FNC that requires that.

Is this mix between subroutines that use an assumed-shape and assumed-size arrays possibly causing my problem?

If yes, how could I deal with it, without changing the external codes?

Many thanks,
Rafael

Nevermind, I finally solved the problem.
There was a workspace variable in the external routinewith size smaller than it should be.
Still surpisedthat the debugger did not detect it and that the problem occured only when I generated parallel code.
Anyway, many thanks for the help!

[Steven_L_Intel1]

There's no problem doing what you have here. By the time the array gets to CALFUN, it is an "adjustable array" with defined bounds. If it was assumed-size here, the compiler would complain.