2

Delphi 7 Service アプリケーション、Indy、Synapse、Zeolibs などで多くのコンポーネントを使用しています。

私のアプリケーションは概ね安定しており、Eurekalog 6 を使用して例外を捕捉していますが、まれに、呼び出したサードパーティ関数がハングしたために一部のスレッドがハングすることがあります。

多くの場合、ハングしたアプリケーションは私の顧客の場所であり、私は彼らのコンピューターにアクセスできないため、ライブ デバッグを行うことはできません。私のアプリケーションは高可用性を必要とするため、1 年に 1 回ハングアップしても、ユーザーには受け入れられません。

私は現在、デバッグが不可能であるが、アプリケーション自体を回復する必要があるような状況に対処するための最良の方法を探しています。呼び出した関数がハングした場合、スレッドが終了する可能性はありますか? あるいは、サービス全体を再起動することもできます。ウォッチドッグはどうですか?それを実装する最良の方法は何ですか? ありがとう。

4

2 に答える 2

10

あなたはかなり敗北者だと思います。バグを見つけて修正します。トリッキーかもしれませんが、それは正しい解決策です。

あなたが理解していない振る舞いをしているスレッドを殺すことは決して解決策ではありません。スレッドを強制終了し始めると、事態はさらに悪化する可能性があります。これにより、他のランタイムエラー、デッドロックなどが発生する可能性があります。スレッドを強制終了し始めると、制御を失います。

これで、(特定のスレッドではなく)プロセスを強制終了し、ウォッチドッグサービスに依存してプロセスを再起動しても安全です。しかし、それは本当に悲惨な解決策です。

予期しない例外をデバッグするには、madExcept、EurekaLogなどのツールを使用する必要があります。すでにEurekaLogを使用しているようですが、それは良いことです。

デッドロック(デッドロックがあるように聞こえます)は、追跡するのがより難しい場合があります。デッドロックをデバッグする良い方法の1つは、クライアントにクラッシュダンプを生成させることです(たとえば、Process Explorerから)。次に、map2dbgを使用してWinDbgでデバッグし、シンボリックスタックトレースを生成します。これにより、どのスレッドがブロックされているかがわかり、デッドロックが明らかになります。そして、バグを修正します。

このデッドロックデバッグ手法の詳細については、http://capnbry.net/blog/?p=18を参照してください。

madExceptを使用しているため、EurekaLogに精通していませんが、EurekaLogには、ハングしたプロセスのスレッドスタックトレースを生成できる機能があると思います。もしそうなら、それはおそらくあなたにとって最良のアプローチでしょう。

于 2012-08-15T18:40:47.743 に答える
2

あなたの質問はかなり漠然としています。使用しているさまざまなコンポーネントのどれを非難したいのかわからない場合、それを修正する見込みはありません. 最も可能性が高いのは、何か間違ったことをしている、またはこれらのコンポーネントがどのように機能するかを理解していないことです。それが純粋にコンポーネント自体のバグであるとはとても思えませんが、いずれにせよ、何が問題なのかを見つけ、それを修正するのはあなたの仕事です。

作成したデッドロック、または発生している深刻なプロセス破損の問題により、MadExcept が情報を提供できない場合がありますが、試してみる価値があります。

どれがフリーズしているかを確認するには、madexcept コメントがこれまでで最高の提案です。(設定可能な秒数の後に) タイムアウトになり、人為的な例外が発生して、ハングしたプロセスが中断されます。これは、ユーザー コード、および Win32 またはカーネル関数でスレッドがブロックされている場所で機能します。たとえば、最近の Indy 10 のデフォルトである無限のタイムアウト用に Indy を設定している可能性があります。また、タイムアウトに関連するフリーズが発生している可能性があります。ネットワーク アクティビティが完了すると予想していたが、決して完了しませんでした。プログラムが「ハング」する原因となります。ここでの解決策は、タイムアウトを変更することです。

ただし、問題がどこにあるのかを把握するまで、修正できるとは思えません。そのためにも、マーカスの言うとおりです。madExcept を調べる必要があります。私はそれなしでは生きていけない。

次に、トレース ロジックをプログラムに実際に追加する必要があります。これにより、問題が発生する直前に、プログラムがどこに行き、何をしていたかがわかります。そのために本当に助けが必要な場合は、Raize の CodeSite を試すことができます。個人的にはOutputDebugString、無料の MicrosoftDebugViewユーティリティ (以前は SysInternals から提供されていた) ツールと組み合わせると、クライアント コンピューターでこのような問題をデバッグするのに十分であることがわかりました。

トレース ログを記録しないバックグラウンド スレッドを持つプログラムは、設計が不適切なプログラムです。失敗したり問題が発生したりする可能性のある重要なシングル スレッド アプリケーションには、トレース ログが必要です。

MadExcept やその他の例外ツールが役に立たない場合でも、ロギングは常に役に立ちます。CodeSite も非常に人気がありますが、Trace-Logging は通常、独自のソリューションです。

于 2012-08-15T19:02:23.857 に答える