了解Valgrind（一）

还有三天，北京的奥运，中国的奥运，大幕即将拉开，一场精彩的盛宴即将开始，想想就让人兴奋。

在奥运的这几周，我估计没什么太多的工作，so今天随意翻了翻Valgrind的用户手册，简单做个记录。

1. Valgrind tool suite提供了几个“代码调试和程序分析”工具，其中最有名的是Memcheck，一个内存检查工具，可以检测常见的内存错误，如：
   • 访问内存“越界”
   Touching memory you shouldn’t (eg. overrunning heap block boundaries, or reading/writing freed memory).
   • 使用没有初始化的值 
     Using values before they have been initialized.
   • 不正确的内存释放
     Incorrect freeing of memory, such as double-freeing heap blocks.
   • 内存泄漏  
     Memory leaks.
   
2. Memcheck只是Valgrind tool Suite中的一个工具，其他工具还有Cachegrind,Callgrind,Massif,Helgrind以及一些正处于“试验阶段”的工具。每一个工具完成属于自己的一块功能。
   
3. 准备工作
   编译时加上选项-g，包括详细的Debugging信息，这样可以让Memcheck的结果中包含精确的行号
   使用-O0(代价是“忍受奇慢的速度”)或者-O1（行号可能不太准确），不推荐-O2及以上
   
4. 运行分析
   valgrind --leak-check=yes myTestprog arg1 arg2
   运行时，你的程序将比平时慢20-30倍，同时使用大量的内存（平时的两倍以上）
   
5. 结果分析
   Memcheck的错误报告含大量的信息，要认真阅读；
   通常错误报告分几个段落，每个段落包含一个错误（每个段落的第一行会告诉你这是什么类型的错误）。下面的信息是详细的追踪过程（Stack Trace）。建议的阅读顺序是“从下往上”，它揭示的是代码的调用顺序，也就是错误发生的过程。
   
   一般情况下，代码的地址不重要，但有时候通过代码地址，可以发现一些“怪异”的bug
   
6. 修改代码
   推荐按照Memcheck报告的错误顺序修改代码，因为后边的错误可能是由前面的错误引起的。
   
   Memcheck报告的泄漏一般有两种类型：
   "definitely lost" 非常明确的内存泄漏，一定要修改。
   "probably lost" 如果你不是在“指针操作”，那么你的程序也在内存泄漏。
   
7. 总结
   Memcheck并不完美，有时候也会误报。你可以禁止“已知的误报”，不过你要小心使用，因为根据大家的经验，Memcheck的错误报告99%的情况下都是正确的。禁止“误报”一般只适用于对“库代码”的报告，因为你不能修改它。
   
   Memcheck并不能检查所有的内存错误，如不能检测数组“访问越界”（静态分配内存），但它应该能检测到能导致程序崩溃的大多数错误。
   
   尽可能的使你的代码“Memcheck clean”，这是可以做到的。如KDE 3.5.x以及openoffice 2.3.x及以上版本都是Memcheck clean，或者非常接近。