Debugging problems

[Simon_Geard]

This question related to v 16.0.3 with VS 2010 (Win7/64).

I am have great difficulty debugging code in this setup. The main problem is that the line number where, e.g., an uninitialized variable is used bears no relation to where the variable actually is, and stepping through the code will step through comments. I have ensured the pdb file is kept up to date but don't really know what else to do. I have just tried compiling a file and even that reports an incorrect line number for the error. Does anyone else have these problems? How do you make sure that debugging is in sync with the source code?

Thanks.

[mecej4]

Please attach one of the source files that exhibits this behavior, and provide the build-log or state the compiler options used. One possible cause is the use of inconsistent line termination characters (CR, LF) in the file. Another is some level of optimization.

[Steven_L_Intel1]

Your comment about keeping the PDB in sync makes me wonder how you're building the application. I am not aware of a general problem such as you describe (unless perhaps you are enabling optimization, in which case line numbers can be unreliable). Are you building a project using Visual Studio or doing it with a command-line script?

[Simon_Geard]

Visual Studio. The C++ and Fortran code is in the same folder but is built under different projects. The C++ project builds a dll which imports the library created by the Fortran project (which creates a .lib file). As far as I can see the pdb file generated by the Fortran build step isn't used, it's just the pdb file generated when the dll is built that the program uses. For debug builds we have optimization disabled, traceback set and debugging set to full.

[Steven_L_Intel1]

I tried an example C-Fortran solution and the debugging info from the Fortran project was included. To be honest, I am not exactly sure HOW it was picked up. I can see that the Fortran project creates a PDB but am unsure how the C++ project's link finds it. Maybe there's a reference in the object modules. In any case, if you didn't get the Fortran PDB included you'd have no debugging info at all for the Fortran code, rather than the "wrong" info. If you can provide a ZIP with a VS test case that shows the problem I'd be glad to look at it.

[Simon_Geard]

Hi Steve, unfortunately I don't have any code I can send to I public forum but there is some in Premier Support so I've sent you details on this separately.
 

[Steven_L_Intel1]

Here's what I have learned so far. The symptom is that source-line correlation is off by some number of lines in a particular source file. This source file is a submodule that uses fpp preprocessor lines. The shift in debug line correlation is directly related to the number of lines that are #ifdef-ed out in the source preceding the subroutine. For example, if you move the problem subroutine to the top of the submodule, the correlation is correct. As you move it down, past conditionalized-out statements, the shift grows.

I have so far been unable to reproduce this in a simpler test case, but I am still working on it. I haven't yet experimented to see if being a submodule is required.

[Simon_Geard]

Thanks for the info. I have now experimented with removing #ifdef lines and that's improved things considerably. Do you consider this to be a bug?

[Steven_L_Intel1]

I do, but I'm having a difficult time coming up with my own example and that's slowing down my reporting of it. There's clearly more than one thing at work here. I will be working on this again this afternoon.