Debugging Problems

[hkausl]

I have installed Intel Composer Fortran Update 4 with VS 2008 SP1 on a XP-32 bit machine. Now at the moment, I have problems with one of my programs, so I use debugger to fix it. I have some breakpoints, when I reach them, I go on wiht F10. On some breakpoints, this seems not to work. I don't go to the next statment, instead I go to the last breakpoint or keep on standing on the staement. But the program seems to continue, see it on my watches. I don't understand this I rebuild everything, deletet all object-files and so on. The error occurs while reading from a file. For my understanding, debugging and code don't work together in a correct way. In other projets I cheked, this works. Any iea?

[Les_Neilson]

I have noticed something similar - though I am using IVF 11 with VS 2008
Pressing F10 will sometimes act like pressing F5 and instead of going to the next statment will go to the next break point, if any or run through to theend of the executable if not.
This is whatYOU may be seeing, ifyour program hasa do loop, that it has gone round the loop to the "next" breakpoint (which may apear to be the previous breakpoint in your code).

Many times I have had to restart debugging the program again and put extra breakpoints in the routine(s) I am working on.

Les

[mecej4]

The symptoms indicate that some option asking for optimization was in effect at compilation time. Note that the /Zi option does not automatically prevent all optimization. The code transformations that are performed by the compiler result in a weakening of the correlation between instruction pointer and line number, resulting in the symptoms described.

If recompiling with all optimizations turned out is not feasible (as would be the case if, for example, if you were studying an optmizer bug!) I have found the following tactic may help.

When a breakpoint is hit, look in the "Disassembly" tab, and make sure that it shows source code interspersed with assembly code. Look for the next logical breakpoint.

If it is not where you think it should be, add one or more breakpoints. For example, if you placed a breakpoint on a line that contains a function reference, and you want to see the argument that is about to be passed to the function, add a breakpoint before the CALL .. instruction.

If the current breakpoint is not where you think it should be, add more breakpoints, restart, make sure that the newly added breakpoints are active, and try again.

[bmchenry]

one other possible instance where strange jumping aheadin debug may occur is if some of the code is compiled with release instead of debug.
If the first or first few breakpoints is/are isdebug compiled routines, everything loads fine with no complaint of 'missing debug information'.
Then you get to a routine or project within the solution which wasn't compiled in debug and it skips the breakpoint with nary a word.
I've runinto thiswhen manually copying dlls to the debugdirectory and forgettting that some are debug/some release dlls and it happened more than a few times before i realsized it was due to lack of correlation of the debug information and release dll.
(so the lack of a complaint of missing debug information was correct as the 'test' directory is normally the debug directory but when things go wroing sometimes i move release dlls into the directory for additional testing)
lots of words to simply explaina possible reasonfor the missing breakpoints.

[hkausl]

It's correct, the problems where in a do while loop.WhenI create a new procect, Inormally have a release and a debug solution.For my understanding, the debug solution has to work correctly with debugger, therefor the options have to be correct by default.

[Les_Neilson]

Yes one would probably suspect optimization asthe cause of the problem. I can't speak for the OP but I know my debug projects do not have optimization - besides the re-start will very often work just fine, F10 stepping one line at a time, and then suddenly in the same routine will act as if I had pressed F5 :-(
Not a show stopper but annoyingwhen I am debugging something that takes several minutes to get to the point of interest.

Les

[jimdempseyatthecove]

Les, when this (reliably) happens if you use F11 (step into)?

On VS 2005 I've sometimes noticed (infrequently) that the break points sometimes get goofy. A particular difficult situation to debugis when the break (typically INT03 but sometimes INT21) into the code stream NOT at the first byte of the instruction but at some subsequent byte within the instruction. This effectively changes the instruction. To further complicate issues, when you enter a break mode, then when examining code via dissassembly window, all the evidence of the misplaced break point has been removed (i.e. unpatched). The only way to undo this condition (at least that I have found) is to click on the X to delete all break points. This seems to make the debugger to forget about the misplaced break point. I have not experienced this on VS 2010 (didn't have VS 2008).

Jim Dempsey

[Les_Neilson]

I usually place a breakpoint on the first executable statement of a subroutine then step through (F10) examining the data of interest. If the data goes invalid after a CALL FOO then I place a break on the call statement, rerun the program and then step into (F11) the subroutine FOO.

If I forget to put a breakpoint on the first executable of FOO then occasionally pressing F10 (after stepping into FOO)will act as F5 and the program runs to completion or to the next breakpoint.

At other times after hitting the first executable statement breakpoint I thenstep through (F10)the code, watching the data values, andsuddenly it runs to completion or the next breakpoint. I then have to rerun the program until I hit the relevant breakpoint again and then F10 usually steps through ok - same routine FOO, same code. I can't say what the frequency of occurrence is - often enough to be annoying, but not enough to stop me working. Most of the programs I work with have runtimes of single figure minutes.
I wonder if it is related to the number of breakpoints that are set? The way I work they can build up over time.

I don't often have to look at the dissassembly code so I can't say if I've noticed the problem you describe.

Les

[jimdempseyatthecove]

Les,

Let me explain the F11 thing a bit further.

When you are inside a subroutine/function and at a break (either break point or result of post F10, F11 or Shift-F11) .AND. if the next statement is .NOT. CALL or hasa function, then F10 and F11 are perceptually equivilent (advances to next statement), however, the technique used by the debugger is quitedifferent.

F10: Set temporary break point at line of next statement, then F5/run

whereas

F11: Continue in single step mode until line number of current statement changes (this may require multiple hiddenbreaks and single steps by the debugger)

When you debug Release builds it is almost a necessity to use F11 to step through your code (that and setting break points in the Dissassembly window).

N.B. F11 in Debug build can take a long time on some statements when array bounds checking is enabled.

Jim Dempsey

[Les_Neilson]

Thanks Jim I didn't know that. I have only ever (knowingly)used F11 to step into a called subroutine. I think I've only tried to debugRelease version exes once or maybe twice over the last 8 years. Most of my debugging is pretty staightforward with the odd Heisenbug thrown inhere and there to make things interesting.
I have noticed the occasional delays on F11, the array bounds check being the cause makes sense.

Les

[hkausl]

In my case it has nothing to do with F11. The reason seems to be in the loops. Now I place some additional statmets in the loop and go to them with F5. This works. But when I'm in the loops and use F10, this doesn't work correct. Normally I use debugger to avoid additional test code, but here it is my only solution. By the way, I don't use optimization, I use the standard debug profile which was generatet by Composer 2011. If there are some settings, which have to be chacnged, Intel please change them.