Intel® Fortran Compiler 16.0 User and Reference Guide
This topic describes tradeoffs and restrictions that apply to using traceback.
Using the traceback option to get automatic PC correlation increases the size of an image. For any application, the developer must decide if the increase in image size is worth the benefit of automatic PC correlation or if manually correlating PCs with a map file is acceptable.
The approach of providing automatic correlation information in the image was used so that no run-time penalty is incurred by building the information "on the fly" as your application executes. No run-time diagnostic code is invoked unless your application is terminating due to a severe error.
The following routines are used to walk the stack:
For Windows OS, the Windows API routine StackWalk( ) in imagehlp.dll
For Linux OS and for OS X, _Unwind_ForcedUnwind( ), _Unwind_GetIP( ), _Unwind_GetRegionStart( ) and _Unwind_GetGr( ) routines in libunwind.so
In an environment using IA-32 architecture, there are no firm software calling standards documented. Compiler developers are under no constraints to use machine registers in any particular way or to hook up procedures in any particular way. The stack walking routines listed above use a set of heuristics to determine how to walk the call stack. That is, they make a "best guess" to determine how a program reached a particular point in the call chain. With C code that has been compiled with Visual C++* using the Omit Frame Pointer option -- either -fomit-frame-pointer (Linux OS and OS X) or /Oy (Windows OS) -- this "best guess" is not usually the correct one.
If you are mixing Fortran and C code and you are concerned about stack tracing, consider disabling the -fomit-frame-pointer or /Oy option in your C compilations. Otherwise, traceback will most likely not work for you.
Programs can fail for a number of reasons, often with unpredictable consequences. Memory corruption by erroneously executing code is one possibility. Stack memory can be corrupted in such a way that the attempt to trace the call stack will result in access violations or other undesirable consequences. The stack-tracing run-time code is guarded with a local exception filter. If the traceback attempt fails due to a hard detectable condition, the run-time will report this in its diagnostic output message as:
Stack trace terminated abnormally
Be forewarned, however: It is also possible for memory to be corrupted in such a way that a stack trace can seem to complete successfully with no hint of a problem. The bit patterns it finds in corrupted memory where the stack used to be, and then uses to access memory, may constitute perfectly valid memory addresses for the program to be accessing. They just do not happen to have any connection to what the stack used to look like. So, if it appears that the stack walk completed normally, but the reported PCs make no sense to you, then consider ignoring the stack trace output in diagnosing your problem.
Another condition that will disable the stack trace process is your program exiting because it has exhausted virtual memory resources.
The stack trace can fail if the run-time system cannot dynamically load libunwind.so (Linux OS and OS X) or imagehlp.dll (Windows OS) or cannot find the necessary routines from that library. In this case, you still get the basic run-time diagnostic message; you will not get any call stack information.
The following applies to Windows operating systems only.
When incremental linking is enabled, automatic PC correlation does not work. Use of incremental linking always disables automatic PC correlation even if you specify /traceback during compilation.
When you use incremental linking, the default hexadecimal (hex) PC values will still appear in the output. To correlate from the hexadecimal PC values to routine containing the PC addresses requires use of a linker map file. However, if you request a map file during linking, incremental linking becomes disabled. Thus to allow any PC values generated for a run-time problem to be helpful, incremental linking must be disabled.
In the integrated development environment, you can use the Call stack display, so incremental linking is not a problem.