Debugging in release mode

[Intel_C_Intel]

I was wondering if any of you guys knows of any knowledge base article, paper, documentations,... that explains how to debug a code in release mode. My specific program is a hybid of C++ 6.0 and CVF 6.1.A and it runs just fine in debug mode but it crashes in release mode. I used to go into the code and try to figure out what had gone wrong by commenting out and bypassing parts of the code to find out the culprit. But, this approach is rather time consuming and in some occasions it does not even work (it can not detemine which part of the code is the real culprit, because the code may crash in one part of the code while the problem has been initiated in another location).

Please send a copy of your reply directly to my e-mail address at:

asi@enginia.com

[Intel_C_Intel]

Debugging "Release version" code is always a pain because many things that the compiler gives you in debug mode are gone, including default initialization of variables. Look for variables that you check without initializing - I've seen this happen a lot.

Good Luck
-Ronnie

[sabalan]

Have you tried this: While running the Debug Configuration go to Project | Settings... | Fortran | General (or Debug) | Debugging Level and change it from Full to either Partial, Minimal, or None and then try to debug your program. Some variable values will not be seen at these modes but you may possibly find the bug anyway. You may try different Optimization Levels at the same place too.

Regards,
Sabalan.

[Steven_L_Intel1]

I've found it difficult to do debugging from Release configurations, so what I do is go into the Debug configuration and startt bumping up the optimization level. You can start off at Full if you want, but the lower the level at which you can reproduce the problem, the better the debugging will be. Look carefully at the options selected - some things, such as array bounds checking, get turned off in Release configurations.

Steve

[Intel_C_Intel]

Unfortunately, you are going to have to put print statements into the code such as "I'm in this section of the code", "now I'm in this section of the code", etc. to first pinpoint where the problem is occurring in the code. Once you find the section, you will have to pinpoint further to the exact line. Once you find what is causing the problem in this section, you will then have to go back to where all the variables used in the offending line of code are computed and repeat the steps ad infinitum until you get to the root of the problem. This is exactly how programs were debugged back in the mid 70's, over 25 years ago. It will probably take you days to find the problem using this method and maybe even weeks unless you are lucky, but you have little choice with the CVF compiler.

The problem is most likely an uninitialized variable that takes on a zero or quite respectable value when compiled with debug options and a value that causes the program to crash when compiled in the release configuration. In the last year, I have probably spent over 3 months tracking down initialization "errors" for a code (that I did not originally develop) that has worked for the last 25 years using FORTRAN compilers on DEC 10s, VAX 11/750s, Crays, SGis, DEC Alphas, HPs, and every PC FORTRAN compiler ever developed including NDP, Watcom, SVS, Lahey, Absoft, Salford, and even Ryan/McFarland (anyone out there remember that one?) until CVF's compiler. They only beame "errors" after 30 years (it took 5 years development time for the orignal developers) when compiled with CVF.

This is a recurring problem in this forum for CVF users that I have pointed out over and over again. However, CVF has made it very clear that an easy solution for this problem (an option that will ensure you get the same answers in debug and release configurations), an option to initialize all variables to zero, or, better yet, initialize all variables to the largest representable value that will cause an over/underflow when first used, will not be forthcoming.

Their reasoning for not providing a simple solution to a legitimate customer problem (as evidenced by the number of times this problem has appeared in this forum), as best I can figure out, is that forcing the code developer to initialize all variables to what the developer deems appropriate results in a more "correct" program. But pity the poor person who has to deal with "incorrect" code, either what they have developed or someone else has developed that has initialization errors, as you have just found out. So, basically you are SOL for a quick solution unless you can get the program to compile with either Lahey's or Salford's compiler and debug it in their environment. Lone voice, crying into the wilderness............

[Intel_C_Intel]

Thanx for all your replies. I just wanted to give you an update on my progress and the roots of the problem:

Both problems were from interfacing isuues:

1. In the following example "COMPUTE_GAP_VOLTAGES" is in fact a fortran routine that I am calling from C++.

extern "C" void __stdcall COMPUTE_GAP_VOLTAGES(int* iSurface, double* Point1, double* Point2, double* Voltage);

The problem was due to the fact that I missed the "__stdcall" in the above statement. The compiler was not giving me any warning and even the debug mode was running correctly. But, in release mode, the program was crashing in a totally unrelated portion of the code.

2. The second problem was when I was passing messages between the windows in C++.
Here is the right declaration:
LRESULT CLnzTrace::SetData(WPARAM wParam, LPARAM lParam)
which I mistakenly wrot it as:
void CLnzTrace::SetData(void)

Again, this was running just fine in debug mode while causing crashes in release mode.

The moral of the story:

1. It would be nice if there were more stringent checks placed in C++ and Fortran compilers to make sure the interfacing was always correct.

2. It would be nice if a knowledgeable person in Compaq/Microsoft could write down a knowledge based article containing a check list of the most common problems causing a crash in debug mode. Of course, ideally, this article should contain more information than just saying: "Go check all the variables are initialized." It could, for instance contain some information on different optimization levels and the factors that they rule out if they succeed. As Steve and another reader suggested, I could start from debugging mode and using "Custimize optimization levels", gradually set different choices on till the point that I reach the full optimization level. But, without a good knowledge on where to start and the effect that each one of those flags will have on a program that is crashing, it would be an extremely time consuming task for a project containing more than 600 source files.

Ali Asi
asi@enginia.com

[Steven_L_Intel1]

If you were using CVF 6.6, or had selected the "Use Debug C Libraries" option, the C RTL would have detected the calling mechanism mismatch in most cases.

Steve

[Intel_C_Intel]

Steve;

Just wanted to let you know that I activated "Use Debug C Libraries" option in debug mode and also put the wrong interface back in there. I just wanted to see whether compiler or Run Time environment would signal me that something was wrong. Unfortunately, once again the code ran flawlessly in debug mode.

Nevertheless, I will leave that flag on just to be on the safe side from now on.

Ali Asi
asi@enginia.com

[Steven_L_Intel1]

It may be that the stack checking code in the debug C libraries looks only at calls from C.

Steve