系统技术非业余研究

参考资料：http://www.redhat.com/magazine/015jan06/features/valgrind/
http://www.stlinux.com/devel/debug/mudflap

我们用C语言在做大型服务器程序的时候，不可避免的要面对内存错误的问题。典型的问题是内存泄漏，越界，随机乱写等问题。 在linux下valgrind是个很好的工具，大部分问题都可以查的到的。但是对于更微妙的越界问题，valgrind有时候也是无能为力的。比如下面的问题。

[admin@my174 ~]$ cat bug.c

int a[10];
int b[10];
int main(void) {
   return a[11];
}

[admin@my174 ~]$ gcc -g -o bug bug.c
[admin@my174 ~]$ valgrind ./bug
==5791== Memcheck, a memory error detector.
==5791== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==5791== Using LibVEX rev 1658, a library for dynamic binary translation.
==5791== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==5791== Using valgrind-3.2.1, a dynamic binary instrumentation framework.
==5791== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==5791== For more details, rerun with: -v
==5791== 
==5791== 
==5791== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 1)
==5791== malloc/free: in use at exit: 0 bytes in 0 blocks.
==5791== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
==5791== For counts of detected errors, rerun with: -v
==5791== All heap blocks were freed -- no leaks are possible.
[admin@my174 ~]$ 

valgrind报告一切安好。

[admin@my174 ~]$ gcc -o bug bug.c -g -fmudflap -lmudflap
[admin@my174 ~]$ ./bug
*******
mudflap violation 1 (check/read): time=1285386334.204054 ptr=0x700e00 size=48
pc=0x2b6c3013c4c1 location=`bug.c:5 (main)'
      /usr/lib64/libmudflap.so.0(__mf_check+0x41) [0x2b6c3013c4c1]
      ./bug(main+0x7a) [0x400952]
      /lib64/libc.so.6(__libc_start_main+0xf4) [0x39ea21d994]
Nearby object 1: checked region begins 0B into and ends 8B after
mudflap object 0x16599370: name=`bug.c:1 a'
bounds=[0x700e00,0x700e27] size=40 area=static check=3r/0w liveness=3
alloc time=1285386334.204025 pc=0x2b6c3013bfe1
number of nearby objects: 1

mudflap就很顺利的检查出来了。

[admin@my174 ~]$ gcc -v
…
gcc version 4.1.2 20080704 (Red Hat 4.1.2-46)

当然我们的这个例子很简单，典型的服务器要比这个复杂很多， 而且mudflap的运行开销也非常高，我们在定位此类bug的时候不妨实验下。
Have fun!

From: http://lwn.net/Articles/371466/

I am pleased to announce that the GCC Steering Committee has
accepted the contribution of the gccgo front-end and gcc-specific runtime
for the Go language with Ian Taylor appointed maintainer. The GCC
Release Managers will decide the details about the timing of the merge and
inclusion in GCC 4.5 or later.

Please join me in congratulating and thanking Ian and the Go
language developers. Please update your listing in the MAINTAINERS file.

Happy hacking!
David