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