大内高手--调试手段及原理概要.doc

大内高手--调试手段及原理 知其然也知其所以然，是我们《大内高手》系列一贯做法，本文亦是如此。这里我不打算讲解如何使用boundschecker、purify、valgrind或者gdb，使用这些工具非常简单，讲解它们只是多此一举。相反，我们要研究一下这些工具的实现原理。 本文将从应用程序、编译器和调试器三个层次来讲解，在不同的层次，有不同的方法，这些方法有各自己的长处和局限。了解这些知识，一方面满足一下新手的好奇心，另一方面也可能有用得着的时候。 从应用程序的角度 最好的情况是从设计到编码都扎扎实实的，避免把错误引入到程序中来，这才是解决问题的根本之道。问题在于，理想情况并不存在，现实中存在着大量有内存错误的程序，如果内存错误很容易避免，JAVA/C#的优势将不会那么突出了。 对于内存错误，应用程序自己能做的非常有限。但由于这类内存错误非常典型，所占比例非常大，所付出的努力与所得的回报相比是非常划算的，仍然值得研究。 前面我们讲了，堆里面的内存是由内存管理器管理的。从应用程序的角度来看，我们能做到的就是打内存管理器的主意。其实原理很简单： 对付内存泄露。重载内存管理函数，在分配时，把这块内存的记录到一个链表中，在释放时，从链表中删除吧，在程序退出时，检查链表是否为空，如果不为空，则说明有内存泄露，否则说明没有泄露。当然，为了查出是哪里的泄露，在链表还要记录是谁分配的，通常记录文件名和行号就行了。 对付内存越界/野指针。对这两者，我们只能检查一些典型的情况，对其它一些情况无能为力，但效果仍然不错。其方法如下(源于《Comparing and contrasting the runtime error detection technologies》)： l 首尾在加保护边界值 Header Leading guard(0xFC) User data(0xEB) Tailing guard(0xFC) 在内存分配时，内存管理器按如上结构填充分配出来的内存。其中Header是管理器自己用的，前后各有几个字节的guard数据，它们的值是固定的。当内存释放时，内存管理器检查这些guard数据是否被修改，如果被修改，说明有写越界。 它的工作机制注定了有它的局限性: 只能检查写越界，不能检查读越界，而且只能检查连续性的写越界，对于跳跃性的写越界无能为力。 l 填充空闲内存 空闲内存(0xDD) 内存被释放之后，它的内容填充成固定的值。这样，从指针指向的内存的数据，可以大致判断这个指针是否是野指针。 它同样有它的局限：程序要主动判断才行。如果野指针指向的内存立即被重新分配了，它又被填充成前面那个结构，这时也无法检查出来。 从编译器的角度 boundschecker和purify的实现都可以归于编译器一级。前者采用一种称为CTI(compile-time instrumentation)的技术。VC的编译不是要分几个阶段吗？boundschecker在预处理和编译两个阶段之间，对源文件进行修改。它对所有内存分配释放、内存读写、指针赋值和指针计算等所有内存相关的操作进行分析，并插入自己的代码。比如： Before if (m_hsession) gblHandles-ReleaseUserHandle( m_hsession ); if (m_dberr) delete m_dberr; After if (m_hsession) { _Insight_stack_call(0); gblHandles-ReleaseUserHandle(m_hsession); _Insight_after_call(); } _Insight_ptra_check(1994, (void **) m_dberr, (void *) m_dberr); if (m_dberr) { _Insight_deletea(1994, (void **) m_dberr, (void *) m_dberr, 0); delete m_dberr; } Purify则采用一种称为OCI(object code insertion)的技术。不同的是，它对可执行文件的每条指令进行分析，找出所有内存分配释放