7

これは以前に人々に起こったことがあると確信しています。何かがデバッグモードで動作し、リリースでコンパイルし、何かが壊れます。

これは、Embedded XP環境で作業しているときに発生しました。実際にそれを行うための最善の方法は、ログファイルを書き込んでどこで問題が発生するかを判断することでした。

厄介なリリースモードのバグに対処しようとしているあなたの経験/発見は何ですか？

4

9 に答える 9

3

適切なデバッグシンボルが利用可能であることを確認してください（これは、リリースビルドでも、組み込みデバイスでも実行できます）。スタックトレースと、できればいくつかの変数の値を取得できるはずです。この時点では、アセンブリ言語に関する十分な知識も役立つでしょう。

私の経験では、一般的に、バグは破損領域の近くにあるコードに関連しています。つまり、関数「LoadConfigInfoFromFile」で問題が発生している場合は、「DrawControlsOnScreen」ではなく、問題を綿密に分析することから始めるべきです。「遠隔作用」タイプのバグは頻繁に発生する傾向はありません（発生する場合は、主要なクマになる傾向があります）。

于 2008-08-28T21:05:47.047 に答える
2

Tracefile は常に良い考えです。クラッシュに関しては、windows 用のデバッグ ツールの一部である adplus を使用しています。基本的に adplus が行うことは、監視している実行可能ファイルに windbg をアタッチすることです。アプリケーションがクラッシュすると、クラッシュ ダンプとログ ファイルが生成されます。好みのデバッガーにクラッシュ ダンプをロードして、どの命令がクラッシュを引き起こしたかを調べることができます。

リリース ビルドはデバッグ ビルドに比べて大幅に最適化されているため、コードをコンパイルする方法がその動作に影響します。これは基本的に、マルチスレッド コードでクラッシュがリリース バージョンで発生し、デバッグ バージョンでは発生しない場合に当てはまります。adplus と windbg は、これがどこで起こったのかを知るのに役立ちました。

ADPlus についてはこちらで説明しています: httx://support.microsoft.com/?scid=kb%3Ben-us%3B286350&x=15&y=12

1. WinDbg をダウンロードして C:\debuggers httx://www.microsoft.com/whdc/devtools/debugging/default.mspx にインストールします。

  1. アプリケーションを開始する

  2. cmd を開き、c:\debuggers に cd します。

  3. 次のように adplus を起動します。

「adplus.bat -crash your_exe.exe」

  1. クラッシュを再現

  2. vs2005 または windbg でクラッシュダンプを分析する

于 2009-05-26T15:19:59.103 に答える
0

デバッグが必要なのがアプリケーションのごく一部である場合は、これらのソースファイルを変更して、最適化せずにビルドすることしかできません。おそらく、すべてのビルドのデバッグ情報を生成するため、アプリケーションはリリース時とほぼ同じように実行されますが、興味深い部分を適切にデバッグできます。

于 2008-08-28T21:03:30.080 に答える
0

Traceステートメントを使用するのはどうですか。これらは、リリースモードの値をチェックするためにあります。

Trace.WriteLine(myVar);
于 2008-08-28T21:03:41.937 に答える
0

ログファイルのデバッグに同意して、ログファイルを絞り込みます。

クラッシュする前にどのメソッドに入るのかがわかるまで、「EnteringFunctionName」「LeavingFunctionName」を使用しました。次に、ログメッセージをさらに追加して、再コンパイルして再リリースします。

于 2008-08-28T21:06:29.073 に答える
0

pauldooが言ったように、最適化をオフにしたり、リリース ビルドのデバッグ情報をオンにしたりして遊ぶ以外に、ログ ファイルは良いデータを提供します。私はかつて、リリース ビルドの開始時にアプリが実行されていた場合にアプリのトレース ログをキャプチャする "トレース" アプリを作成しました (そうしないと、デバッガーで実行されている場合に結果がデバッガーの出力ウィンドウに表示されます)。エンドユーザーに、彼らが見たバグを再現したログファイルをメールで送ってもらうことができました。これが、少なくとも 1 つのケースで問題を発見できた唯一の方法でした。

于 2008-08-28T21:08:53.453 に答える
0

問題が同期関連の場合、ファイル内のログのダンプに問題がある可能性があります。
この場合、私は通常、文字列の大きな配列を使用し、問題が再現された後にこれを画面/ファイルにダンプします。
もちろん、これはメモリの制限に依存します。プラットフォームのメモリが限られている場合、配列に格納するために少数のシンボルと数字のみを使用することがあります。このようなログを読むことは大きな喜びではありませんが、これが唯一の選択肢である場合があります。

于 2008-09-16T08:47:42.967 に答える
0

おそらく組み込み環境では使用できないかもしれませんが、私はWinDbgでリリース モードの Windows アプリケーションをデバッグすることができました。アプリケーションがシンボル情報を使用してコンパイルされていない場合でも、少なくとも使用可能なスタック トレースとその他の有用なクラッシュ情報を多数取得できます。

于 2008-08-29T00:17:35.667 に答える
0

リリース モードでコンパイルされている場合でも、デバッグ シンボルを運用環境にコピーすることもできます。

ここは 詳細 な 記事 です .

于 2008-08-29T00:38:22.857 に答える