Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Strange debug location

DavidWhite
Valued Contributor II
381 Views
While trying to debug my code, I stopped at the line
CARATIO=.FALSE.
On pressing F11, debugger attempts to debug a location that is not part of my code, and is not even a location on my system:
f:\\dd\\vctools\\crt_bld\\self_x86\\crt\\src\\gs_support.c
What's happening here?

Thanks

David
0 Kudos
3 Replies
jimdempseyatthecove
Honored Contributor III
381 Views
F11 is stepping into a C Runtime Library function which was built on someone else's system. The Debug information in the object file (within the library) is pointing to the path as used on the other system.

Either use F10 (i.e. do not step into)

Or, if you have the source to this library located elsewhere on your system, the debugger has a property sheet where you can specify alternate locations for program source files. (use this property to point to the location of your copy of this source file (gs_support.c)

Jim Dempsey
0 Kudos
DavidWhite
Valued Contributor II
381 Views
Jim,

how can I be stepping into a C Runtime Library on this simple assignment statement?

I am not including any C projects in my application, althoughI am using RealWin. I have all the source files, several are which areCfiles, but nothing with this name, and definetely not with anything on F:, which does not exist on my system.

It is a mystery where this link comes from.

Regards,


David
0 Kudos
jimdempseyatthecove
Honored Contributor III
381 Views
F: (and path) is that of the machine of the developer that produced the library function.
This could be someone from Microsoft, Intel, etc...
The library is loaded/linked because the file name appears with the debug information in your file.

If you can place a break point at this statement and then run to this statement without going to la la land, then run to break, open a dissassembly window, and step into (F11) with that window open until you see the next statement is a program transfer (branch, call, ret, jmp, ...). See if the transferwill beinto this library or out of your program.

If your statement has a goofy branch... then possibly your code got overwritten by something.

If nothing unusual appears...

Get pen and paper (or open newtext file in the IDE)
Do the F11 thing *** and write down where you are in the code, include the hex address. Doing copy and paste with the mouse works.

If youdiscover a ret instruction takesyou into thegoofy routine then this indicates that your code destroyed the return address on the stack.

This will be a good learning experience for you.
Reading dissassembly is not as hard as it looks.

Jim Dempsey
0 Kudos
Reply