# Tradeoffs and Restrictions in Using Traceback

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

## Effect on Image Size

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 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:

- For Windows*, the Windows API routine StackWalk( ) in imagehlp.dll

- For Linux* and for macOS, _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 and macOS) 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:

    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. 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 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 runtime system cannot dynamically load libunwind.so (Linux and macOS) 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 Operating Systems

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 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.

Parent topic: Traceback