1

締め切りがあります。私はグーグルしています、私はコードを読んでいます、私は助けが必要です...

私のアプリケーションはEStackOverFlowをスローしています。エラーを見つけるには一晩のテストが必要なので、いくつかの良いアイデアが必要です。そうしないと、追跡するのに長い時間がかかります。

昨夜MADExceptで試しましたが、スタックがなかったためか、うまくいきませんでした。IDEから実行していたので、実行を中断してコールスタックを確認しましたが、詳細を除いてMADでいっぱいでした（作成者に連絡しましたが、時間差が大きくなっています）。

（意図的に）再帰的な再帰ルーチンはありません。OnChangeハンドラーはありません（モニターするコンポーネントを誤って変更し、再帰的に呼び出す可能性があります）。大きなデータ構造はありません（パラメーターとしてスタックに渡される可能性があります）。

私の最初の考えは、MADをオフにすることですが、クラッシュするまでさらに12時間または16時間待つことはできません。

無人で、タイマーが30秒ごとまたは1時間ごとに期限切れになると、プログラムはデータベースアクセスを実行するため、クラッシュを早めることを期待して、タイマーを1秒に設定しました。うーん、クラッシュを早めるためにスタックサイズを減らすことはできますか？もしそうなら、どのように？

他に何ができますか？フォームが作成され、アプリケーションが実行されるアプリケーションのメインファイルをTry...Exceptでラップしました。

メッセージ処理ループなど、スタックサイズをチェックして、スタックサイズが「大きすぎる」かどうかを確認できるポイントはありますか？（もしそうなら、あなたは詳細を与えることができますか？）

他に何か提案はありますか？前もって感謝します

（psコードが大きすぎて投稿できません）

4

2 に答える 2

1

最も一般的なスタックオーバーフローの問題は、関数がそれ自体を呼び出すか、回避しようとするか、少なくとも制限することです。

タイマーを使用していると言いますが、タイマーイベント内でApplication.ProcessMessagesを呼び出していますか？キューにたくさんのメッセージがある場合、別のWM_TIMERの場合は、スタックオーバーフローが発生する可能性があります。

于 2012-09-20T09:44:48.693 に答える
1

なので。上記のプロファイラーアプローチは、運が良ければ結果が得られる可能性があります（まれですが、瞬時に高速なリークにつながる漂遊分岐がある場合。たとえば、100のケースバリアントの中で、無限再帰につながるのは1つだけです）。ただし、蓄積するのに一晩かかる安定した累積リークがある場合、プロファイラーの結果は通常の作業と区別できません。

少し考えました。現在の仮説は、スタックが残っていないためにスタックトレーサーが失敗するというものです。抱きしめましょう。次に、スタックが終了する前に例外をスローしますね。だから私はこのシーケンスを試してみます：

1）行番号を含む完全なスタックトレースをログに記録するようにスタックトレーサーを設定します。これは、Delphi IDEで使用されるJCLトレーサーで実行できますが、madExceptでも実行できると思います。

2）現在のスタックサイズを知りたいのですが。たとえば、VisualStudioを使用したスタックスペースの決定

3）使用済みのスタックスペースを定期的にチェックします。たとえば、安全な最大スタックサイズとは何ですか？スタックの使用を測定する方法は何ですか？

注：どのスレッドがこれを引き起こしたかはほとんどわからないため、スレッドが少ない場合は、それらすべてを使用しようとします。一部の補助スレッドがSOで失敗した場合、アプリケーションがどのように反応するかわかりません。それを傍受してログに記録することはできますか、それとも1つのスレッドだけでアプリ全体が爆破される可能性があります。

4）〜5分ごとに、現在のスタックの使用状況をログに記録します-パターンを確認するためだけに、パターンが着実にゆっくりと進んでいる場合、またはまれですが深刻なコードパスである場合。 複数のスレッドの場合-スレッドごとに1つの複数のログファイル 「通常の」スタック使用量を見積もることもできます。

5）スタック使用量が80％を超えた場合（上記の「通常の」使用量todlはそれを超えないと思いますよね？）手動例外を発生させます。これは、スレッド/アプリケーションがトップになるまでキャッチされない特別なクラスです。レベル、そしてトップレベルでは、アプリをデバッガーに停止して目覚めさせるなど、複雑なことを行うこともできます。これにより、リモートで接続して、病気であるがまだ死亡していないアプリの内部ステータスを確認できます。

于 2012-09-20T06:02:08.847 に答える