C++ 内存泄漏检测原理_1

void *operator new(size_t) throw(std::bad_alloc); void *operator new[](size_t) throw(std::bad_alloc); void operator delete(void*) throw(); void operator delete[](void*) throw();
使用中我们发现，在某些特殊情况下（请直接参看 debug_new.cpp 中关于 DEBUG_NEW_FILENAME_LEN 部分的注释），文件名指针会失效。因此，目前的 debug_new 的缺省行为会复制文件名的头 20 个字符，而不只是存储文件名的指针。另外，请注意原先 new_ptr_list_t 的长度为 16 字节，现在是 32 字节，都能保证在通常情况下内存对齐。
不过，如果不包含 debug_new.h，这种方法就起不了作用了。不仅如此，部分文件包含 debug_new.h，部分不包含 debug_new.h 都是不可行的。因为虽然我们使用了两种不同的 operator new --"operator new(size_t, const char*, int)"和"operator new(size_t)"-- 但可用的 "operator delete"还是只有一种！使用我们自定义的"operator delete"，当我们删除由"operator new(size_t)"分配的指针时，程序将认为被删除的是一个非法指针！我们处于一个两难境地： 要么对这种情况产生误报，要么对重复删除同一指针两次不予报警：都不是可接受的良好行 为。
前面已经提到，要得到精确的内存泄漏检测报告，可以在文件开头包含"debug_new.h"。 我的惯常做法可以用作参考：
ቤተ መጻሕፍቲ ባይዱ
#ifdef _DEBUG #include "debug_new.h" #endif 包含的位置应当尽可能早，除非跟系统的头文件（典型情况是 STL 的头文件）发生了 冲突。在某些情况下，可能会不希望 debug_new 重定义 new，这时可以在包含 debug_new.h 之前定义 DEBUG_NEW_NO_NEW_REDEFINITION，这样的话，在用户应用程序中应使用 debug_new 来代替 new（顺便提一句，没有定义 DEBUG_NEW_NO_NEW_REDEFINITION 时也可以使用 debug_new 代替 new）。在源文件中也许就该这样写： #ifdef _DEBUG #define DEBUG_NEW_NO_NEW_REDEFINITION #include "debug_new.h" #else #define debug_new new #endif 并在需要追踪内存分配的时候全部使用 debug_new（考虑使用全局替换）。 用户可以选择定义 DEBUG_NEW_EMULATE_MALLOC，这样 debug_new.h 会使用 debug_new 和 delete 来模拟 malloc 和 free 操作，使得用户程序中的 malloc 和 free 操作也可 以被跟踪。在使用某些编译器的时候（如 Digital Mars C++ Compiler 8.29 和 Borland C++ Compiler 5.5.1），用户必须定义 NO_PLACEMENT_DELETE，否则编译无法通过。用户还可 以使用两个全局布尔量来调整 debug_new 的行为：new_verbose_flag，缺省为 false，定义为 true 时能在每次 new/delete 时向标准错误输出显示跟踪信息；new_autocheck_flag，缺省为 true，即在程序退出时自动调用 check_leaks 检查内存泄漏，改为 false 的话用户必须手工调 用 check_leaks 来检查内存泄漏。 需要注意的一点是，由于自动调用 check_leaks 是在 debug_new.cpp 中的静态对象析构 时，因此不能保证用户的全局对象的析构操作发生在 check_leaks 调用之前。对于 Windows 上的 MSVC，我使用了"#pragma init_seg(lib)"来调整对象分配释放的顺序，但很遗憾，我不 知道在其他的一些编译器中（特别是，我没能成功地在 GCC 中解决这一问题）怎么做到这 一点。为了减少误报警，我采取的方式是在自动调用了 check_leaks 之后设 new_verbose_flag 为 true；这样，就算误报告了内存泄漏，随后的 delete 操作还是会被打印显示出来。只要泄 漏报告和 delete 报告的内容一致，我们仍可以判断出没有发生内存泄漏。 Debug_new 也能检测对同一指针重复调用 delete（或 delete 无效指针）的错误。程序将 显示错误的指针值，并强制调用 abort 退出。 还有一个问题是异常处理。这值得用专门的一节来进行说明。
void* operator new(size_t size, const std::nothrow_t&); 其中，nothrow_t 通常是一个空结构（定义为"struct nothrow_t {};"），其唯一目的是提供 编译器一个可根据重载规则识别具体调用的类型。用户一般简单地使用"new(std::nothrow) 类型"（nothrow 是一个 nothrow_t 类型的常量）来调用这个 placement new 操作符。它与标 准 new 的区别是，new 在分配内存失败时会抛出异常，而"new(std::nothrow)"在分配内存失 败时会返回一个空指针。 要注意的是，没有对应的"delete(std::nothrow) ptr"的语法；不过后文会提到另一个相关 问题。 要进一步了解以上关于 C++语言特性的信息，请参阅[Stroustrup1997]，特别是 6.2.6、 10.4.11、15.6、19.4.5 和 B.3.4 节。这些 C++语言特性是理解本实现的关键。
g++ test.cpp debug_new.cpp -o test
输出结果如下所示： Leaked object at 0x805e438 (size 10, <Unknown>:0) Leaked object at 0x805e410 (size 4, <Unknown>:0)
如果我们需要更清晰的报告，也很简单，在 test.cpp 开头加一行 #include "debug_new.h"
文件名、行号、对象大小信息分别存入 file、line 和 size 字段中，然后返回(malloc 返回的指
针 + sizeof(new_ptr_list_t))。在 delete 时，则在链表中搜索，如果找到的话（(char*)链表指
针 + sizeof(new_ptr_list_t) == 待释放的指针），则调整链表、释放内存，找不到的话报告删
一个跨平台的 C++ 内存泄漏检测器
简介:
内存泄漏对于 C/C++程序员来说也可以算作是个永恒的话题了吧。在 Windows 下，MFC 的一个很有用的功能就是能在程序运行结束时报告是否发生了内存泄漏。在 Linux 下，相对 来说就没有那么容易使用的解决方案了：像 mpatrol 之类的现有工具，易用性、附加开销和 性能都不是很理想。本文实现一个极易于使用、跨平台的 C++内存泄漏检测器。并对相关的 技术问题作一下探讨。
对于"new int"，编译器会产生一个调用"operator new(sizeof(int))"，而对于"new char[10]"， 编译器会产生"operator new[](sizeof(char) * 10)"（如果 new 后面跟的是一个类名的话，当然 还要调用该类的构造函数）。类似地，对于"delete ptr"和"delete[] ptr"，编译器会产生"operator delete(ptr)"调用和"operator delete[](ptr)"调用（如果 ptr 的类型是指向对象的指针的话，那在 operator delete 之前还要调用对象的析构函数）。当用户没有提供这些操作符时，编译系统自 动提供其定义；而当用户自己提供了这些操作符时，就覆盖了编译系统提供的版本，从而可 获得对动态内存分配操作的精确跟踪和控制。
除非法指针并 abort。
至于自动检测内存泄漏，我的做法是生成一个静态全局对象（根据 C++的对象生命期，
在程序初始化时会调用该对象的构造函数，在其退出时会调用该对象的析构函数），在其析
构函数中调用检测内存泄漏的函数。用户手工调用内存泄漏检测函数当然也是可以的。
基本实现大体就是如此。
可用性改进
上述方案最初工作得相当好，直到我开始创建大量的对象为止。由于每次 delete 时需要 在链表中进行搜索，平均搜索次数为(链表长度/2)，程序很快就慢得像乌龟爬。虽说只是用 于调试，速度太慢也是不能接受的。因此，我做了一个小更改，把指向链表头部的 new_ptr_list 改成了一个数组，一个对象指针放在哪一个链表中则由它的哈希值决定。--用户可以更改宏 DEBUG_NEW_HASH 和 DEBUG_NEW_HASHTABLESIZE 的定义来调整 debug_new 的行 为。他们的当前值是我测试下来比较满意的定义。
即可。添加该行后的输出如下： Leaked object at 0x805e438 (size 10, test.cpp:5) Leaked object at 0x805e410 (size 4, test.cpp:4)