7

最近、非常に卑劣なバグに遭遇しました。このバグでは、文字列（char配列）へのポインタを逆参照するのを忘れて、スタックの1バイトを上書きすることがありました。

悪い：

char ** str;
(*str) = malloc(10);
...
str[2] = 'a'; //overwrites 3 bytes from the location in which str is stored

修正：

char ** str;
(*str) = malloc(10);
...
(*str)[2] = 'a';

GCCは警告を生成しませんでした。このエラーは、時々上書きされた値がバッファのサイズを保持していたため、非常に深刻で実際の悪用につながりました。運が良かったのでこのバグを見つけただけで、明らかに失敗しました。

  • 運に頼ったり、Cをまったく使用しないこと以外に、奇妙なCのバグをキャッチするためにどのような防御的なコーディング手法とトリックを使用しますか？

  • valgrindのMemCheckに移行することを考えていますが、誰かがそれを使用しましたか？このバグは捕まえられなかったのではないかと思います。誰か知ってる？

  • ポインタの逆参照や算術バグをキャッチするためのツールはありますか？それも可能ですか？

アップデート

リクエストされたサンプルコードは次のとおりです。警告はスローされません。

#include <stdlib.h>

void test(unsigned char** byteArray){
    (*byteArray) = (unsigned char*)malloc(5);
    byteArray[4] = 0x0;
}

int main(void){
    unsigned char* str;
    test(&str);  
    return 0;
}

コンパイルしてもエラーは発生しません。

gcc -Wall testBug.c -o testBug

実行すると、セグメンテーション違反が発生します。

./testBug
Segmentation fault

これは私が使用しているGCCのバージョンです：

gcc -v

Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.1-4ubuntu9' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-targets=all --disable-werror --with-arch-32=i486 --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu9)
4

5 に答える 5

3

私の最善の防御的ポインター戦略：複数レベルの間接参照の使用は強く避けてください。ポインタからポインタへの間接参照を参照してメモリを割り当てても問題ありません。しかし、割り当てられたメモリを配列として使用することは、問題を引き起こします。私はそれを次のようにします：

char **outStr;
*outStr = malloc(10);
char *str = *outStr;
str[2] = 10;

OK、実際には、防御的な価値もあるのは、正気を保つ戦略にすぎません。一度に複数のレベルの間接参照が存在しない場合、ポインターはかなり理解しやすく、よく理解していればコードを正しく機能させるのは簡単です。

于 2010-02-02T18:23:55.063 に答える
1

私はValgrindを使用しています、それは命の恩人です！

valgrind --tool=memcheck -v ./yourapp

そして、MemCheckは、 `str [2] ='a';´で無効な書き込みがあることを検出します。

于 2010-02-02T18:17:18.833 に答える
1

GCCはあなたに与えるべきです

 warning: assignment makes pointer from integer without a cast

いいえ？

于 2010-02-02T18:23:06.310 に答える
1

Valgrindを使用してください。これは、私が出会った中で最高のメモリチェックツールの1つです。それは確かにあなたのエラーを検出します。

valgrindは、メモリエラーの検出とは別に、メモリリーク、使用中のメモリブロックなどの検出にも役立ちます。

IBM Rational Purifyでさえ、そのようなエラーの検出に役立ちます。私の個人的なお気に入りはValgrindですが。

于 2010-02-02T18:44:58.953 に答える
0

私の提案はツールではありませんが、ベストプラクティスであるテストです。このようなバグは通常、最下位レベルの単体テストから始めて、コードを厳密にテストすることで非常に簡単に見つけることができます。

表示するコードが正しい結果を生成することは決してありません。これは、機能する場合と機能しない場合があります。そのコードの単体テストを行うことで、後でシステムの他の部分と統合するときにデバッグの時間を節約できます。

単体テストは、カバレッジチェックによって補完できます。自動ツールを使用するか、コードを手動でスキャンして各部分を対象とするテストを作成します。これは、実際にはコード（別のデバッグツール）を再読み込みするための優れた方法であり、驚くほど効果的です。 。

于 2010-02-02T18:44:57.423 に答える