Oracle® Solaris Studio 12.4: Performance Analyzer

Exit Print View

Updated: January 2015

Incomplete Stack Unwinds

Stack unwind is defined in Call Stacks and Program Execution.

    Stack unwind might fail for a number of reasons:

  • If the stack has been corrupted by the user code. The program might core dump, or the data collection code might core dump, depending on exactly how the stack was corrupted.

  • If the user code does not follow the standard ABI conventions for function calls. In particular, on the SPARC platform, if the return register, %o7, is altered before a save instruction is executed.

    On any platform, hand-written assembler code might violate the conventions.

  • If the leaf PC is in a function after the callee’s frame is popped from the stack but before the function returns.

  • If the call stack contains more than about 250 frames, the Collector does not have the space to completely unwind the call stack. In this case, PCs for functions from _start to some point in the call stack are not recorded in the experiment. The artificial function <Truncated-stack> is shown as called from <Total> to tally the topmost frames recorded.

  • If the Collector fails to unwind the frames of optimized functions on x86 platforms.

Intermediate Files

If you generate intermediate files using the -E or -P compiler options, Performance Analyzer uses the intermediate file for annotated source code, not the original source file. The #line directives generated with -E can cause problems in the assignment of metrics to source lines.

The following line appears in annotated source if there are instructions from a function that do not have line numbers referring to the source file that was compiled to generate the function:

function_name -- <instructions without line numbers>

    Line numbers can be absent under the following circumstances:

  • You compiled without specifying the -g option.

  • The debugging information was stripped after compilation, or the executables or object files that contain the information are moved or deleted or subsequently modified.

  • The function contains code that was generated from #include files rather than from the original source file.

  • At high optimization, if code was inlined from a function in a different file.

  • The source file has #line directives referring to some other file. This situation can occur if compiling with the -E option and then compiling the resulting .i file. It might also happen when you compile with the -P flag.

  • The object file cannot be found to read line number information.

  • The compiler used generates incomplete line number tables.