web-dev-qa-db-ja.com

DLLの例外を処理する方法？

私は最近、C++ビルダーで作成された既存のプロジェクトに取り組み始めました。アプリケーションは、モジュール（DLL）のlotsをロードするMainModuleで構成されています。 MainModule自体はDLLです（MainModuleを起動する小さなローダー（.exe）があります）。

ロードされたモジュール（DLL）のいずれかに問題が発生しても、MainModuleはクラッシュしません。したがって、例外がモジュールを離れないのは命令です。したがって、各DLLには、内部のすべての例外をトラップするグローバルなtry/catchがあります。

コードをよりコンパクトにするために、例外が使用されますeverywhere for

  • フロー制御
  • シグナリング
  • エラーログ（何か問題が発生すると、例外ハンドラーがメッセージをコンソールに出力します）

デバッグはコンソールに表示されるメッセージに基づいて行われ、printf行がコードに挿入されて、プログラムが関数の特定のポイントに到達したかどうかが確認されます。

どうすればこれらのDLLをデバッグできますか？
問題は、これらのプラグイン/ DLLの1つでアクセス違反が発生すると、グローバルなtry/catchが例外をキャッチすることです。メインのアプリケーション/デバッガーに到達することはありません。

注：コードはレビューされます。したがって、既存のコードにできる限り小さな変更を加えることも命令的です！

c++exceptionsdebuggingabstractionproject-structure
3
Ultralisk

私はあなたの問題への2つのアプローチを見ます：

  • ハンドルされていない例外だけでなく、例外がスローされたときにブレークするようにデバッガーを構成します。これは私が通常選択するアプローチですが、例外が例外イベントにのみ使用され、常に使用される場合にのみ機能します。そのため、アプリケーションにうまく適合していないようです。

    一部のデバッガーでは、例外の種類に基づいてこの設定を構成できます。したがって、コードベースで頻繁に発生する例外に対して2番目のアプローチを使用する一方で、発生してはならない例外（アクセス違反など）に対してこのアプローチを使用できます。

  • DLLのグローバル例外ハンドラーにブレークポイントを設定できます。

    _if(_ IsDebuggerPresent() _)_ __debugbreak() _;_に沿ったもの

    残念ながら、スタックの一部はすでにその時点で展開されており、デバッグに役立つ多くの情報が削除されています。

それについて何もできる可能性は低いですが、アクセス違反は通常、回復不可能な例外と見なされます（メモリ破損が原因で発生する可能性があるため）。プロセスを許可するのではなく、終了する別のプロセスを使用して、フォールアウトを抑制する必要があります。このようなエラーが発生した場所で続行します。

2
CodesInChaos

一般に、構造化例外を「飲み込む」ことは非常に危険です。あなたが意図的に自分自身を引き起こした例外を除いてそうしているのですか？ I. E. segfaultを飲み込むと、プロセスが微妙に破損し、後で問題が発生したときに問題をデバッグできなくなる可能性があります。

可能であれば、別のプロセスでサブモジュールを分離することをお勧めします

3
Bwmat