DeBug vs Release

DeBug vs Release

I frequently encounter bugs that only occur in the release version. When I run my fortran program in debug mode I will not get an error. I have had to resort to debugging by putting print statements in release mode - ouch! Does anyone know why this happens and what can be done about it?

7 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

It usually happens because of programming errors that get brought out by optimization. Try, in debug mode, setting the optimization level to "Full" to see if the error occurs. The higher the optimization level, the less useful the debugger is, but maybe you'll get a clue.


Retired 12/31/2016

I made the same experience when I was still using Fortran 77. The problem was normally that a variable passed to a subroutine was not of the correct type. Compiling in debug mode the type was changed automatically before passing it but with the optimizations enabled this was not done, the memory got screwed up and the program broke down somewhere. The problem was that the program never broke down at the position where the actual error was, but at a totally different position. Putting a print statement in the code solved the problem temporarily but the program would break down at a different position later. So maybe you should check all your interfaces and the corresponding subroutine calls.

I also have a lot of problems similar to what you have described. One cause of the problem is that there is no compiler option to initialize all variables to zero. Depending upon whether or not I compiled with the debug or release options, I obtain very different results from the code. This is because with certain compiler options, some variables are initialized to zero, and with other options, the same variables are not set to zero, resulting in not only run time errors, but very different results when the code runs to completion. Obviously, this makes debugging within the CVF environment impossible if you get different results depending upon the compiler options.

One of the things you might want to do is check to make certain all variables are initialized to zero before they are assigned a value. This will not necessarily prevent run time errors with and without debug options, but at least you will (hopefully) get the same answers when running the debug and release versions, with the possibility that this will clear up your problem. It is beyond my understanding why there is no option to zero out variables other than this does not conform to the FORTRAN standard. Forcing a programmer to initialize all variables does not mean that the programmer will initialize them correctly, which apparently is the philosophy behind this approach. It just forces me to put in a lot of extraneous statements into the code just to get the code to run. Oh well..........

If you relied on a compiler switch to zero variables, you would be papering over a bug in your code and would make your program non-portable. It is best for the programmer to correctly initialize all variables before use - the programmer knows better than the compiler what the correct values should be.


Retired 12/31/2016


In theory, what you say is correct. However, in practice this results in code that gives different answers depending upon the compiler options chosen. I emphasize that this makes it impossible to debug a program in the CVF debugging environment. The code developer has to resort to putting in print statements in the code. Forcing a programmer to initialize all variables does not automatically ensure that the programmer will initialize them correctly. The reason why the code becomes nonportable is because this is not part of standard FORTRAN, which was a decision by the standards committee. The best approach I have seen is in Salford's compiler which has an option to set initial values for variables that will cause the program to stop whenever the value of a variable is accessed that contains this value. At least by always initializing all variables to a given starting value, the code will always reproduce the same results regardless of what compiler options are chosen (assuming that the compiler options chosen don't affect the precision of calculations).


I think you've found that Steve is correct in theory and in practice. If all variables are correctly initialized in code by the programmer then this will not give different answers depending on chosen compiler options; in fact, it would help prevent this. It's more the practice of not initializing variables that may make debugging impossible, not a missing compiler switch to do the initializations. How should a "compiler option to initialize all variables to zero" handle strings? How about logicals? What about a square matrix called Identity? What about compound types, unions, allocatable arrays, pointers, integer pointers? Who, if not the programmer, is capable of correctly initializing variables in the context of that program?

The work putting in print statements is better applied to correct initialization code. Initializing all variables in code is simply good coding practice.
FWIW, IMO other good practices include, but certainly are not limited to: implicit none, explicit interfaces, argument intent.


Leave a Comment

Please sign in to add a comment. Not a member? Join today