7

I recently ran into a very sneaky bug, in which I forget to dereference a pointer to a string (char array) and thus sometimes overwrote one byte on the stack.

Bad:

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

Corrected:

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

GCC produced no warnings, and this error would've resulted in a very serious and real exploit as the value it sometimes overwrote held the size of a buffer. I only caught this bug because I got luckly and it caused an obvious failure.

  • Other than relying on luck and/or never using C for anything, what defensive coding techniques and tricks do you use to catch wierd C bugs?

  • I'm thinking about moving to valgrind's MemCheck, has anyone used it? I suspect it wouldn't have caught this bug. Anyone know?

  • Are there tools for catching pointer dereferencing or arithmetic bugs? Is that even possible?

UPDATE

Here is the requested example code, it does not throw any warnings.

#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;
}

Compiling causes no errors:

gcc -Wall testBug.c -o testBug

Running causes a seg fault:

./testBug
Segmentation fault

This is the version of GCC I'm using:

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;

好吧，实际上这只是一种保持理智的策略，恰好也具有防御价值。当一次不超过一个间接级别时，指针相当容易理解，并且当您理解它时更容易使代码正常工作。

于 2010-02-02T18:23:55.063 回答
1

I use Valgrind, it's a lifesaver!

valgrind --tool=memcheck -v ./yourapp

And MemCheck will detect that you have an invalid write with `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。这是我遇到的最好的内存检查工具之一。它肯定会检测到您的错误。

除了检测内存错误，valgrind 还有助于检测内存泄漏、正在使用的内存块等。

甚至IBM Rational Purify也会帮助您检测此类错误。虽然我个人最喜欢的是 Valgrind。

于 2010-02-02T18:44:58.953 回答
0

我的建议不是工具，而是最佳实践：测试。从最低级别的单元测试开始，通过严格的代码测试通常很容易发现此类错误。

您显示的代码永远不会产生正确的结果 - 它有时不起作用，有时不起作用。对那段代码进行单元测试可以在以后与系统的其他部分集成时节省数小时的调试时间。

单元测试可以通过覆盖检查来补充：要么使用自动工具，要么只是手动扫描代码并编写针对每个部分的测试——这实际上是重新阅读代码（另一个调试工具）的好方法，并且非常有效.

于 2010-02-02T18:44:57.423 回答