スタック展開の定義については、呼び出しスタックとプログラムの実行を参照してください。
スタック展開は、次のようないくつかの場合に失敗します。
スタックがユーザーコードによって破壊された場合。スタックが破壊された原因によっては、プログラムでコアダンプするか、またはデータ収集コードでコアダンプする場合があります。
ユーザーコードが、関数呼び出しの標準の ABI 規則に従っていない場合。特に、SPARC プラットフォームで、保存命令が実行される前に復帰レジスタ %o7 が変えられる場合。
どんなプラットフォームでも、手書きのアセンブラコードには規則違反がある場合があります。
リーフ PC の関数内の位置が、呼び出し先のフレームがスタックからポップされたあとで、かつ関数が復帰する前である場合。
呼び出しスタックに約 250 を超えるフレームが含まれている場合、この呼び出しスタックを完全に展開するだけの領域がコレクタにはありません。この場合、呼び出しスタックの _start から特定の時点までの関数の PC は実験ファイルに記録されません。擬似関数 <Truncated-stack> は、記録されたいちばん上のフレームを集計するために <Total> から呼び出されたものとして示されます。
x86 プラットフォームで、最適化された関数のフレームをコレクタが展開できなかった場合。
-E または -P コンパイラオプションを使用して中間ファイルを生成すると、パフォーマンスアナライザは元のソースファイルではなく、この中間ファイルを注釈付きソースコードとして使用します。-E を使用して生成された #line ディレクティブは、ソース行へのメトリックの割り当てで問題が発生する原因となることがあります。
関数が生成されるようにコンパイルされたソースファイルへの参照用の行番号を持たない関数からの命令が存在する場合、次の行が注釈付きのソースに現れます。
function_name -- <instructions without line numbers>
行番号は、次の条件下では欠落することがあります。
-g オプションを指定しないでコンパイルした場合。
コンパイルのあとにデバッグ情報がストリップされた場合、またはその情報を含む実行可能ファイルかオブジェクトファイルが移動、削除、変更された場合。
関数に、元のソースファイルからではなく、#include ファイルから生成されたコードが含まれている場合。
高レベルの最適化で、コードが異なるファイルの関数からインライン化された場合。
ソースファイルに、ほかの何らかのファイルを参照する #line ディレクティブが含まれている場合。この状況は、-E オプションでコンパイルしたあと、結果の .i ファイルをコンパイルした場合に発生することがあります。また、-P フラグでコンパイルした場合にも発生する可能性があります。
行番号情報を読み取るオブジェクトファイルが見つからない場合。
使用したコンパイラが、不完全な行番号テーブルを生成する場合。