1

プロジェクトに重大なバグがあります。gdb を使用して .core を開くと、次のようなものが表示されます (読みやすくするために、すべての gdb 出力を入れていません)。

これは非常に疑わしい、新しく書かれたコードの一部です::

0x00000000004579fe in http_chunk_count_loop 
 (f=0x82e68dbf0, pl=0x817606e8a Address 0x817606e8a out of bounds)

これはコードの非常に成熟した部分であり、長い間問題なく動作していました::

0x000000000045c8a5 in packet_handler_http 
 (f=0x82e68dbf0, pl=0x817606e8a Address 0x817606e8a out of bounds)

さて、私の心を混乱させているのはpl=0x817606e8a Address 0x817606e8a out of bounds、 gdb は、新しく書かれたコードに到達する前に、それがすでに範囲外だったことを示しています。これは、 を呼び出す関数によって引き起こされる問題を考えさせますpacket_handler_http。

しかしpacket_handler_http、非常に成熟しており、問題なく長期間機能しています。そして、これにより、gdb出力を誤解しています。

問題はpacket_handler_http私が推測するところにありますが、これはすでに機能しているコードであるため、混乱しています。私の推測は正しいですか、それとも何か不足していますか?

4

3 に答える 3

4

「メモリ エラー」を検出するには、Valgrind でプログラムを実行します: http://valgrind.org

シンボル ( -ggcc 用) を使用してプログラムをコンパイルした場合、エラーが発生したコード行に至るまで、"範囲外" 状態を確実に検出できます。

于 2013-08-20T15:10:55.293 に答える
2

あなたの貢献に感謝します。

新しいコードに範囲外の問題を引き起こす部分がありました。

:: (goodpointer + offset) のような行があり、このオフセットは http チャンク サイズであり、ネットワーク (データ スニッフィング) から取得していました。そして、このオフセットが非常に大きく、整数オーバーフローを引き起こすという一種の攻撃がありました。そして、これは範囲外の問題を引き起こしました。

私の結論：ネットワークからパラメータを決して突き出さないでください。クラッシュの瞬間にスタックが乱雑になる可能性があるため、gdbは常にコアダンプでパラメータを正しく指すとは限りません。

于 2013-08-22T07:49:14.287 に答える
2

問題は packet_handler_http にあると思います

その推測が正しい可能性は低いです。packet_handler_httpが実際に無効なポインタを受け取っている場合は、その「上流」で破損が発生しています。

これはコードの非常に成熟した部分であり、長い間問題なく機能していました

10 年以上「問題なく」動作していたコードのバグを定期的に見つけます。また、新しく追加されたコードで破損が発生している可能性がありますが、他の場所で問題が発生しています。ヒープとスタックのバッファ オーバーフローは、多くの場合、まさにそのようなものです。

alk が既に提案したように、実行可能ファイルをValgrindまたはAddress Sanitizer (GCC-4.8 にも含まれています) で実行し、見つかった問題を修正します。

于 2013-08-21T07:13:26.890 に答える