Debugging Fortran applications on Intel platforms running Windows

Intel_C_Intel · ‎06-28-2004

Hi, I'm Gordon, the Debugger Consultant for Intel's Software Products Division. I'm responsible for enabling and promoting effective debugging on Intel platforms in general, and with the Intel Debugger in particular.

My current focus is on creating a repository of Best Known Methods for debugging serial, thread parallel and cluster parallel applications.

I'd like to get a feel for how the community at large approaches application debugging. I'm curious to know things like:

What types of bugs do you encounter most often?
What types of bugs do you find most difficult to locate and fix?
What methods do you use to accomplish this?
Which debuggers do you tend to use (and why)?
Which debuggers do you prefer to use (and why)?
Which debugger features do you find yourself using most often?
Which new debugger features would you consider to be essential?

Please feel free to contribute accordingly. I appreciate your participation, it helps significantly to improve both the processes and the tools for all of us.

Thanks!

Jugoslav_Dujic · ‎06-29-2004

What types of bugs do you encounter most often?

Stupid ones :-).

What types of bugs do you find most difficult to locate and fix?

When the program crashesonly whenreleasebuild is ran from outside the debugger, especiallyon another OS (2000->XP)

What methods do you use to accomplish this?

I accomplish these bugs usually by 1) uninitialized variables, usually ALLOCATEd ones 2) silent out-of-bounds access beyond assumed-size arrays. None is catchable by either IVF or CVF. If you mean, "to accomplish debugging" :-), I've used various techniques, where "dissection method" using trace output is the most effective, if it can be called effective at all. There are few other, such as determination of crash line by building release configuration with debug info and comparison of assembly addresses between the one seen in debugger and one reported by crash dialog.

Which debuggers do you tend to use (and why)?

Which debuggers do you prefer to use (and why)?

Built-in ones in Visual Studio.

Which debugger features do you find yourself using most often?

Which new debugger features would you consider to be essential?

1) Uninitialized variables check

2) Uninitialized variables check

3) Uninitialized variables check

4) "Attach to process" feature which works (contrary to the one built-in in VS6 and VS.NET)

Not exactly a debugger issue, but Ithink that current relying on VC++ run-time libraries has few downsides. The main problem with libcd.lib is that its malloc, on which ALLOCATE is based (afaik) initializes heap memory with 0xCDCDCDCD or 0xBAADF00D bit-pattern, whichare very bad choices. CVF debugger does not take advantage by ever checking the bit pattern in question, too. That bit-pattern evaluates to large negative integer orsmall positive real, and the codes typically written as

do i = 1, iUninitialized(i)

x = y(i)

end do

where iUninitialized(i) typically should be zero in correct code, do not ever crash under the debugger because the execution is skipped (as it should be). They do crash when ran from shell though, when iUninitialized gets a random positive integer. Ditto for floating-point operations, where fUninitialized(i) yields TRANSFER(#BAADF00D,F) = -1.3270393E-03, which can pass unnoticed because it's rather close to zero.

I'd like to see the ability to 1) detect "suspicious" bit pattern and raise an exception when it's encountered and 2) at least, the uninitialized memory should be filled with something like 0x7FF07FF0, which gives NaN for both real(4) and real(8) and alarge positive integer.

Oh, yes, and working "Attach to process" feature.

I could think of few more useful features for a debugger, but the current state of the art of CVF and IVF debuggers is rather useful as it is now.

Jugoslav

tonyjay68 · ‎06-29-2004

What types of bugs do you encounter most often?

Ones created from my own incompetence.

Which new debugger features would you consider to be essential?

Warn if variable used before being initialised. The salford debugger / compiler has this and I miss it !.

Tony

durisinm · ‎06-29-2004

The bugs I encounter most often and the ones I find most difficult to fix are the same: logic errors from my coding.

To fix most errors I set breakpoints and examine the values of variables.

The debugger I use most often is the one built into Visual Studio. I don't know how to use Intel's debugger. Is there a short how-to document available?

A feature--although not necessarily a debugger feature--that would be great to have is the easy construction of a calling tree.

Another good feature would be an easier way to stop a program when certain conditions (changing of a variable's value, a variable's value reaching a certain limit, etc.) occur. I did this kind of debugging only a few times in CVF, and I've never tried it in IVF. My experience with CVF was that I had to really dig to find the appropriate documentation, and once I had the debugging commands set up the program ran very slowly.

I believe that Intel's debugger is a text-based one. As I said previously, I've never used it, but as a model to emulate I would take a look at the text-based debugger for OpenVMS. It has lots of features that aren't that hard to learn and use, and it does a good job of tracing execution from the main program to subprograms and to shared images, which I believe are very similar to DLLs in the Windows world. It also does a good job of tracing execution between objects in different languages, like Fortran and C.

I realize that the debugger in Visual Studio is from Microsoft and not Intel, so I'm not sure there's much you can do about some of the things I mentioned.

Mike D.

tmcole · ‎06-29-2004

I have harped on this several times before, but was given short shrift. As Jugoslav, Tony, and Mike have stated, what is desperately needed is:

1. to have a runtime error given whenever an uninitialized variable is used on the right hand side of an assignment statement.

2. in lieu of 1, a way to initialize all variables to the largest possible value for integer and floating point values, or set to NAN, or some other value that will cause a runtime error when appropriate flags are set

3. in lieu of 2, a way initialize all variables to zero, .false., etc. through use of a compiler switch

Basically, my previous response to suggestions 1, 2, and 3 have been

1. too much effort/higher priorities

2. bad idea/fosters bad programming techniques

3. bad idea/fosters bad programming techniques

My problem with the response to 2 and/or 3 has always been, who appointed the compiler police? In other words,implementation of either of these would make my life considerably easier, but because not initializing every variable manually is considered bad programming practice, we (the compiler police)are going to force you to do this whether you like it or not.

Because of this stubborn insistence to not initialize variables to some consistent value (pick one, just be consistent), one ends up with code that runs fine in the debugger but blows up when compiled with optimizations turned on. The ONLY way to debug code like this is to go back in time 30 years ago and put write statements in the code until you track down the problem. There is absolutely NO EXCUSE for this behavior in a compiler as a solution is easy to implement.

There, I've got that off my chest and feel immensely better.

Steven_L_Intel1 · ‎06-29-2004

The compiler does now offer /Qzero.

The uninitialized variable issue is not really for the debugger. This is a compiler issue. We're well aware of it and are not shrugging it off.

Intel_C_Intel · ‎06-29-2004

Wow, thanks for all the good dialog.

Many of you may want to try compiling with maximum standards compliance (which also helps with portability) and all warnings turned on. The Intel compiler does do a good job with static analysis and reporting of potential problems. And as Steve mentioned, the /Qzero option is a step in the right direction.

That certainly doesn't take the place of seeding uninitialized variables with specific values, but it should help for the time being.

I've heard that the next version of VSmay provide a robust static analysis feature that will produce control flow (i.e. call graph) and cross reference reports as well as feature usage reports (i.e. potential errors due to violations of recommended coding practices, etc). I haven't heard yet whether or not they'll be providing this for Fortran users, but time will tell...

Has anyone tried one of the "Super Lint" programs for Fortran?

Most of the other issues mentioned can be addressed in IDB with the Trace and Watchpoint mechanisms.

I'll write more specifically about these features and how they can be used to your advantagesometime within the next few days.

In the mean time, please be aware that IDB does provide both a command line interface and a built-in graphical interface. The GUI isn't yet as polished (or as feature rich) as the one in the VS debugger, but it's functional and should do most of what you'll need it to.

Please feel free to share additional (preferably related) thoughts as they come to mind.

Thanks again.

-- Gordon

g_f_thomas · ‎06-29-2004

My forum colleagues have done well, anything I could add would be repetitious and redundant.

"I've heard that the next version of VS may provide a robust static analysis feature that will produce control flow (i.e. call graph) and cross reference reports as well as feature usage reports (i.e. potential errors due to violations of recommended coding practices, etc). I haven't heard yet whether or not they'll be providing this for Fortran users, but time will tell..."

It's no secret that NuMega (corporate neighbors of Intel in Nashua) and/or John Robbins (formally of NuMega) have a hand in VS.NET debugger development. I don't see why they would be adverse to accommodating Fortran, quite the opposite. I used to use suggestions from John's BugSlayer column in MSJ to debug D/CVF (with occassional advise from John) before traceback became a feature and a certain user (not me for a change, :-)) would harass Steve about DVF's failure to email him the line and starting column of his latest error.

Ciao,
Gerry T.

PS Good of you to solicit user opinion on this matter. Bravo.

durisinm · ‎06-30-2004

"I'll write more specifically about these features and how they can be used to your advantagesometime within the next few days."

If this is referring to a relatively short get started/how-to article about the Intel debugger with pointers to the detailed documentation, then it would be great.

Is there any way for Intel tostartits debugger from within VS, giving users a choice of which debugger to start? I'd gladly make the effort to learn how to use it if that were the case. It seems to me that if the Intel debugger has to be started from outside VS then it would make the code, compile, run, debug cycle a bit "choppy."

Mike D.

Intel_C_Intel · ‎07-01-2004

This is for Jugoslav really, but since he brought it up on this thread...

I was interested to know what problems you have had with 'Attach to process...', it always works fine for me (in VC6 / CVF 6.6 environment anyway)

Jugoslav_Dujic · ‎07-01-2004

Now that you mentioned it, Judd, I tried few random samples and it works indeed....

...except forour mainapplication, which is about the only one I ever wanted to debugin this way. :-(. Murphy's law I guess.

Jugoslav

Intel_C_Intel · ‎07-01-2004

Typical :o)

I would also echo that 'Release Build only' bugs are the hardest to debug, and agree we've peppered textual output through our code a few times.

We most recently came across this with an 'quiet' array bounds violation, though turning on the array bounds checking was enough to find this (which we then turned off again, once the bug was fixed).

Typically though, our first step would be to turn on 'Stop Always' for every kind of exception (instead of 'Stop if not handled').

Dan

Intel_C_Intel · ‎07-01-2004

Gerry, I certainly agree that John Robbins is a (if not the) leading authority on debugging as a discipline. I'm glad to hear that he's involved in the development of the VS.NET debugger. It would be very helpful to see the new static analysis capabilities made available to Fortran programmers. Fingers crossed.

Mike, yes, I'll provide a relatively short get started/how-to article about the Intel Debugger with pointers to the detailed documentation. In fact, the documentation is available both in the Intel Debugger installation directory and on the web here.

The Intel Debugger isn't yet integrated with VS.NET (like the Intel Compilers are). However, it does contribute a component called FEE (the Fortran Expression Evaluator) during installation. This component improves the VS.NET debugger's ability to work with Fortran codes. It will likely be further enhanced over time to give Fortran programmers who use the Intel Compilers a much improved debugging experience.

Judd, given that the compiler writes its debug information to an external PDB file, debugging the released version of a program doesn't have to be a headache.

Consider the following that I just cut from an article on "Debugging the release version of a program". It's based on an excerpt from a John Robbins article from 1998:

Something a lot of programmers don't know is that you can debug the release version of a program as easy as the debug version.

In MSVC you can set all of your project's configurations in the Project Settings dialog.

Select the All Configurations option in the Settings For combobox.

On the C/C++ tab, select Program Database in the Debug info combobox.

On the Link tab, with the Category combobox on Debug, check the Debug info checkbox and the Microsoft format.

If you use your own make file use /Zi switch with CL.EXE and use the use the /DEBUG and /PDB: switches for LINK.EXE

That's all there is, now you can set breakpoints and watch variables as usual.

Be aware that due to the optimizer not all symbols can be watch and the execution of the line may be in a different order!

A common error that affects only the re lease version of a program is when you use ASSERT instead of VERIFY. Remember ASSERTs will compile to nothing in a release version but VERIFY does. So if you call a function like ASSERT(DoSomething()) this function will not be called in the release version!

A release version of a program can behave different than the debug version due to optimizer settings. If you find a strange/buggy behavior disable every optimization and try again.

You can do the same with the Intel Compilers.

I hope that helps.

Cheers,

- Gordon