0

プログラムのコール スタックを見て、各リターン ポインターをトークンとして扱う場合、プログラムの有効な状態の認識機能を構築するには、どのような種類のオートマトンが必要ですか?

当然のことながら、特定のバグ状態の認識機能を構築するには、どのようなオートマトンが必要ですか?

(注:この関数から取得できる情報のみを見ています。)

私の考えでは、これらが通常の言語を形成する場合、それを中心にいくつかの興味深いツールが構築される可能性があります。たとえば、一連のクラッシュ/障害ダンプが与えられた場合、それらを自動的にグループ化し、既知のバグの新しいインスタンスを識別するためのレコグナイザーを生成します。

注: これは診断ツールとしてではなく、大量のクラッシュ レポートをより便利なものに変えるためのデータ管理ツールとして提案しています。

  • 「これらの 54 回のクラッシュは、42 回のクラッシュと同様に関連しているようです。」
  • 「これらの新しいクラッシュは、日付 X 以前のものとは何の関係もないようです。」
  • 等

私が何を達成しようと考えているのかが明確ではないように思われるので、以下に例を示します。

3 つのバグがあるプログラムがあるとします。

  • 無効な引数が 1 つの関数に渡され、同じサニティ チェックをトリップさせる 2 つのバグ。
  • (有効な) コーナーケースが与えられた場合、無限再帰に入る関数。

また、プログラムがクラッシュすると (アサートの失敗、キャッチされない例外、seg-V、スタック オーバーフローなど)、スタック トレースを取得し、その上の呼び出しサイトを抽出して、QA レポート サーバーに送信します。(1.プロジェクトごとに1回の費用で簡単に取得できること、2.プログラムに関する特別な知識がなくても使用できる単純で明確な意味があるため、その情報のみが抽出されると仮定しています)

私が提案しているのは、着信レポートを既知のバグの 1 つに関連するものとして (または新しいバグとして) 分類しようとするツールです。

最も単純なことは、1 つの障害サイトが 1 つのバグであると仮定することですが、最初の例では、2 つのバグが同じ場所で検出されます。次に簡単なのは、スタック全体が一致するように要求することですが、2 番目の例のように、同じバグを引き起こす可能性のある (有効な) 有効なコードが複数ある場合、これは機能しません。

4

2 に答える 2

0

スタック上のリターンポインタは、メモリへの単なるポインタです。理論的には、1つの関数呼び出しを行うだけのプログラムの呼び出しスタックを見ると、（その1つの関数の）戻りポインターは、プログラムの実行ごとに異なる値を持つ可能性があります。それをどのように分析しますか？

理論的には、マップファイルを使用してコアダンプを読み取ることができます。しかし、そうすることは非常にプラットフォームとコンパイラに固有です。どのプログラムでもこれを行うための一般的なツールを作成することはできません。コンパイラのドキュメントを読んで、事後分析を行うためのツールが含まれているかどうかを確認してください。

于 2010-04-09T22:17:56.130 に答える
0

プログラムが assert ステートメントで装飾されている場合、各 assert ステートメントは有効な状態を定義します。アサーション間のプログラム ステートメントは、有効な状態変更を定義します。

クラッシュするプログラムは、何かが壊れているという十分なアサーションに違反しています。

正しくないが「不安定」なプログラムは、少なくとも 1 つのアサーションに違反していますが、失敗していません。

あなたが探しているものはまったく明確ではありません。assert有効な状態は、定義するのが難しい場合もありますが、通常は単純なステートメント として簡単に表すことができます。

クラッシュしたプログラムは 1 つ以上のアサーションに違反しているため、明示的な実行可能なアサーションを含むプログラムは、クラッシュのデバッグを必要としません。assert ステートメントに単に失敗し、目に見えて死ぬだけです。

assert ステートメントを入れたくない場合は、どの状態が true であるべきで、どの (実際には述べられていない) アサーションが違反されたかを知ることは本質的に不可能です。

コール スタックを巻き戻して位置とネスティングを解決するのは簡単です。しかし、それが何を示しているかは明らかではありません。何が壊れたかはわかりますが、他の何が壊れたのかはわかりません。それには、どのアサーションが真であると想定されているかを推測する必要があり、これには設計に関する深い知識が必要です。

編集。

「関連していると思われる」および「関連していないと思われる」は、実際のアプリケーションの実際の設計と、各スタック フレームで真であるべき実際のアサーションに頼らずには定義できません。

真であるべきアサーションがわからない場合は、変数のランダムな水たまりしかありません。ランダムな値の山が与えられた場合、「関連」について何を主張できますか?

Crash 1: a = 2, b = 3, c = 4 

Crash 2: a = 3, b = 4, c = 5

関連している？無関係？コードについてすべてを知らずに、これらをどのように分類できますか? コードについてすべて知っていれば、真であるべきassert標準ステートメントの条件を定式化できます。そして、実際のクラッシュが何であるかがわかります。

于 2010-04-09T21:28:39.113 に答える