Intel® Fortran Compiler Classic and Intel® Fortran Compiler Developer Guide and Reference

ID 767251
Date 11/07/2023
Public

A newer version of this document is available. Customers should click here to go to the newest version.

Document Table of Contents

Traceback Tradeoffs and Restrictions

This topic describes tradeoffs and restrictions that apply to using traceback.

Effect on Image Size

When you use the traceback option to get automatic Program Counter correlation, it increases the size of an image. For any application, you must decide if the increase in image size is worth the benefit of automatic Program Counter correlation or if manually correlating Program Counters with a map file is acceptable.

The approach of providing automatic correlation information in the image was used so that no runtime penalty is incurred by building the information "on the fly" as your application executes. No runtime diagnostic code is invoked unless your application is terminating due to a severe error.

C Compiler Omit Frame Pointer Option on Systems Using IA-32 Architecture

The following routines are used to walk the stack:

  • Linux

    _Unwind_ForcedUnwind( ), _Unwind_GetIP( ), _Unwind_GetRegionStart( ) and _Unwind_GetGr( ) routines in libunwind.so

  • Windows

    The Windows API routine StackWalk( ) in imagehlp.dll

When 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) or /Oy (Windows) -- 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.

Inlined Routines Will Not Be Displayed

Inlining can cause some routines not to be realized as separate stack frames, so the traceback will not show inlined routines.

Stack Trace Failure

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 runtime code is guarded with a local exception filter.

If the traceback attempt fails due to a hard detectable condition, the runtime will report this condition in its diagnostic output message as follows:

Stack trace terminated abnormally

Be forewarned that 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. However, they 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 Program Counters 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 runtime system cannot dynamically load libunwind.so (Linux) or imagehlp.dll (Windows) or cannot find the necessary routines from that library. In this case, you still get the basic runtime diagnostic message; you will not get any call stack information.

Linker /incremental:no Option on Windows

When incremental linking is enabled, automatic Program Counter correlation does not work. Use of incremental linking always disables automatic Program Counter correlation even if you specify /traceback during compilation.

When you use incremental linking, the default hexadecimal (hex) Program Counter values will still appear in the output. To correlate from the hexadecimal Program Counter values to routine containing the Program Counter 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 Program Counter values generated for a runtime 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.