4

絶対に理解できないバッファオーバーランがあります(Cで)。まず第一に、それはおそらく 10% 程度の確率でしか発生しません。毎回DBから引き出されるデータは、実行間でそれほど異なるようには見えません...少なくとも、いつ発生するかについて識別可能なパターンを見つけるのに十分な違いはありません。Visual Studio からの正確なメッセージは次のとおりです。

hub.exe でバッファ オーバーランが発生し、プログラムの内部状態が破壊されました。Break を押してプログラムをデバッグするか、Continue を押してプログラムを終了します。

詳細については、ヘルプ トピック「バッファ オーバーランの問題をデバッグする方法」を参照してください。

デバッグすると、コンパイラの /GS フラグからのものであると確信している壊れていることがわかり、__report_gsfailure()これはヒープではなくスタックでのオーバーランであることも示しています。また、それが終了するときにこれをスローした機能もわかりますが、この動作を引き起こす可能性のあるものは何も見えません。この機能は長い間存在していました (10 年以上、若干の変更はありますが)私が知る限り、これは一度も起こったことはありません。

関数のコードを投稿したいと思いますが、かなり長く、多くの独自の関数/変数/などを参照しています。

私は基本的に、私が探していないものを探しているか、おそらく役立つツールを探しているだけです。残念ながら、私が見つけたほぼすべてのツールは、ヒープでのオーバーランのデバッグにしか役立ちません。私が間違っていない限り、これはスタック上にあります。前もって感謝します。

4

5 に答える 5

3

バッファの両端にいくつかのローカル変数を配置するか、(わずかに拡張された) バッファ自体にセンチネルを配置して、それらの値が本来あるべきと思われる値でない場合はブレークポイントをトリガーすることができます。明らかに、データにありそうもないパターンを使用することは良い考えです。

于 2010-04-30T18:52:57.613 に答える
3

Windows では役に立ちませんが、Valgrindはメモリの動作不良を検出するための最良のツールです。

スタックをデバッグしている場合は、低レベルのツールを使用する必要があります。スタック フレーム (おそらく 0xA5 のようなもので満たされたバッファー) にカナリアを配置して、潜在的な容疑者を囲みます。デバッガーでプログラムを実行し、どのカナリアが適切なサイズではなくなり、適切なコンテンツを含んでいるかを確認します。これを行うとスタックの大部分をむさぼり食いますが、何が起こっているのかを正確に突き止めるのに役立つ場合があります。

于 2010-04-30T18:45:19.107 に答える
1

このような謎のバグを絞り込むために私が過去に行ったことの 1 つは、 という名前のグローバルな可視性を持つ変数を作成することでしたcheckpoint。犯人関数の中で、checkpoint = 0;一番最初の行として設定しました。次に、++checkpoint;関数呼び出しまたはメモリ操作の前後にステートメントを追加しましたが、それらが範囲外のメモリ参照を引き起こす可能性があると少しでも疑っていました (さらに、少なくとも 10 行ごとにチェックポイントが作成されるように、コードの残りの部分にペッパーを追加しました)。とか、ぐらい)。プログラムがクラッシュした場合、 の値によって、checkpoint注目する必要のある範囲が数行のコードに絞り込まれます。これは少しやり過ぎかもしれませんが、私は組み込みシステムでこの種のことを行っています (ツールのようなものvalgrindは使用できません) が、それでも有用なはずです。

于 2010-04-30T20:47:28.643 に答える
0

このプログラムはまったく再発しますか?もしそうなら、私はあなたが無限の再帰バグを持っていないことを確認するためにそこでチェックします。手動で表示できない場合は、頻繁に一時停止してスタックを監視することで、デバッガーでキャッチできる場合があります。

于 2010-04-30T20:28:37.887 に答える
0

例外ハンドラーでラップし、発生時に有用な情報をダンプします。

于 2010-04-30T18:47:06.877 に答える