2

このバグをクラックする方法についての良いアイデアが不足しています。2 ～ 3 回の実行ごとにクラッシュする 1000 行のコードがあります。これは現在、C で記述されたプロトタイプのコマンド ライン アプリケーションです。問題は、これがプロプライエタリであり、ソースを提供できないことですが、Debian Squeeze x86_64 マシンの勇敢な魂にデバッグ コンパイル済みの実行可能ファイルを喜んで送信します。

これが私がこれまでに得たものです：

  1. GDB で実行すると、常に正常に完了します。

  2. Valgrind で実行すると、常に正常に完了します。

  3. この問題は、非常に基本的な再帰関数呼び出しから発生しているようです。この再帰関数のエラーを特定するために、別のアプリケーションで同じ関数を作成しました。常に正常に完了します。

  4. 独自の gcc 4.7.1 コンパイラを構築し、それを使用してコードをコンパイルしましたが、それでも同じ動作が得られます。

  5. HW の問題のリスクを排除するためにアプリケーションを別のマシンに FTped しましたが、それでも同じ動作が発生します。

  6. ソース コードを別のマシンに転送して、ビルド環境が破損するリスクを排除しましたが、それでも同じ動作が発生します。

アプリケーションはシングル スレッドであり、競合状態を引き起こす可能性のあるシグナル処理は行いません。私はmemset(,0,)すべての大きなオブジェクト

エキゾチックな依存関係はありません。ldd は以下に従います。

ldd は私にこれを与えます:

ldd tst 
    linux-vdso.so.1 =>  (0x00007fff08bf0000)
    libpthread.so.0 => /lib/libpthread.so.0 (0x00007fe8c65cd000)
    libm.so.6 => /lib/libm.so.6 (0x00007fe8c634b000)
    libc.so.6 => /lib/libc.so.6 (0x00007fe8c5fe8000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fe8c67fc000)

私を助けることができるツールはありますか？あなたが私の立場だったら、次のステップは何ですか？

ありがとう！

これが私を正しい方向に導いたものです-Wextra私はすでに-Wallを使用していました。

ありがとう！！！これは本当に私を夢中にさせていました。

4

2 に答える 2

3

コメントで提案しました：

  • -Wall -Wextra 警告が表示されなくなるまで、ソース コードをコンパイルして改善する。
  • -gと の両方でコンパイルし-Oます。これは、ダンプされたコア ファイルを検査するのに役立ちます(たとえば、 bash ビルトインgdbで十分なコアダンプ サイズ制限を設定することができます)。ulimit
  • コードを同僚に見せて問題を説明するには?
  • 使用するltrace かstrace

どうやら助かっ-Wextraたようです。理由と方法を理解できれば幸いです。

ところで、より大きなプログラムの場合、 MELTで拡張することにより、GCC に独自の警告を追加することもできます。これには数日かかる場合があり、主に大規模なプロジェクトでは価値があります。

于 2012-07-29T15:05:41.703 に答える
0

この場合、メモリに問題があると思います (valgrind の出力を注意深く参照してください)。GDB と valgrind がメモリ追跡関数を追加して元のプログラムを変更します (そのため、元のアドレスが変更されます)。-ggdbオプションを指定してコンパイルし、コアダンプ ( ulimit -c unlimited) を設定して、何が起こっているのかを分析することができます。このリンクはあなたを助けるかもしれません:

http://en.wikipedia.org/wiki/Unusual_software_bug

よろしく。

于 2012-07-29T14:28:52.070 に答える