内存泄漏检测工具

最新推荐文章于 2022-09-22 10:04:24 发布

原创最新推荐文章于 2022-09-22 10:04:24 发布 · 3.8k 阅读

1 ·

CC 4.0 BY-SA版权

文章标签：

#工具 #profiling #microsoft #visualization #dst #java

在嵌入式开发中，内存泄露是很难避免的。往往到项目的后期所有的模块一起来排查内存泄露的问题。如果个人经验很丰富，可以减少一些；不过如果你的模块依赖更底层的东西，而底层的模块出现了内存泄漏，你往往也是唉声叹气。

借助一些开源的检测工具，可以帮助我们发现这些泄露问题。

内存泄漏检测工具

1.ccmalloc－Linux和Solaris下对C和C++程序的简单的使用内存泄漏和malloc调试库。 2.Dmalloc－Debug Malloc Library. 3.Electric Fence－Linux分发版中由Bruce Perens编写的malloc()调试库。 4.Leaky－Linux下检测内存泄漏的程序。 5.LeakTracer－Linux、Solaris和HP-UX下跟踪和分析C++程序中的内存泄漏。 6.MEMWATCH－由Johan Lindh编写，是一个开放源代码C语言内存错误检测工具，主要是通过gcc的precessor来进行。 7.Valgrind－Debugging and profiling Linux programs, aiming at programs written in C and C++. 8.KCachegrind－A visualization tool for the profiling data generated by Cachegrind and Calltree. 9.IBM Rational PurifyPlus－帮助开发人员查明C/C++、托管.NET、Java和VB6代码中的性能和可靠性错误。PurifyPlus 将内存错误和泄漏检测、应用程序性能描述、代码覆盖分析等功能组合在一个单一、完整的工具包中。 10.Parasoft Insure++－针对C/C++应用的运行时错误自动检测工具，它能够自动监测C/C++程序，发现其中存在着的内存破坏、内存泄漏、指针错误和I/O等错误。并通过使用一系列独特的技术（SCI技术和变异测试等），彻底的检查和测试我们的代码，精确定位错误的准确位置并给出详细的诊断信息。能作为Microsoft Visual C++的一个插件运行。 11.Compuware DevPartner for Visual C++ BoundsChecker Suite－为C++开发者设计的运行错误检测和调试工具软件。作为Microsoft Visual Studio和C++ 6.0的一个插件运行。 12.Electric Software GlowCode－包括内存泄漏检查，code profiler，函数调用跟踪等功能。给C++和.Net开发者提供完整的错误诊断，和运行时性能分析工具包。 13.Compuware DevPartner Java Edition－包含Java内存检测,代码覆盖率测试,代码性能测试,线程死锁,分布式应用等几大功能模块。 14.Quest JProbe－分析Java的内存泄漏。 15.ej-technologies JProfiler－一个全功能的Java剖析工具，专用于分析J2SE和J2EE应用程序。它把CPU、执行绪和内存的剖析组合在一个强大的应用中。JProfiler可提供许多IDE整合和应用服务器整合用途。JProfiler直觉式的GUI让你可以找到效能瓶颈、抓出内存泄漏、并解决执行绪的问题。4.3.2注册码：A-G666#76114F-1olm9mv1i5uuly#0126 16.BEA JRockit－用来诊断Java内存泄漏并指出根本原因，专门针对Intel平台并得到优化，能在Intel硬件上获得最高的性能。 附录：内存泄漏的发生方式 1.常发性内存泄漏。发生内存泄漏的代码会被多次执行到，每次被执行的时候都会导致一块内存泄漏。 2.偶发性内存泄漏。发生内存泄漏的代码只有在某些特定环境或操作过程下才会发生。常发性和偶发性是相对的。对于特定的环境，偶发性的也许就变成了常发性的。所以测试环境和测试方法对检测内存泄漏至关重要。 3.一次性内存泄漏。发生内存泄漏的代码只会被执行一次，或者由于算法上的缺陷，导致总会有一块且仅有一块内存发生泄漏。 4.隐式内存泄漏。程序在运行过程中不停的分配内存，但是直到结束的时候才释放内存。严格的说这里并没有发生内存泄漏，因为最终程序释放了所有申请的内存。但是对于一个服务器程序，需要运行几天，几周甚至几个月，不及时释放内存也可能导致最终耗尽系统的所有内存。所以，我们称这类内存泄漏为隐式内存泄漏。

大家可以试用上面的一些工具到自己的项目模块中，这样或许可以帮你发现些什么，不是每个工具都适合你的。

在使用的过程中，可以分析一下这些工具的原理，明白了这些原理，你再写代码时，会主动去规避这些泄露。

==================各个工具的原理========================

来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u/30686/showart_247742.html

从编译器的角度 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)的技术。不同的是，它对可执行文件的每条指令进行分析，找出所有内存分配释放、内存读写、指针赋值和指针计算等所有内存相关的操作，用自己的指令代替原始的指令。 boundschecker和purify是商业软件，它们的实现是保密的，甚至拥有专利的，无法对其研究，只能找一些皮毛性的介绍。无论是CTI还是OCI这样的名称，多少有些神秘感。其实它们的实现原理并不复杂，通过对valgrind和gcc的bounds checker扩展进行一些粗浅的研究，我们可以知道它们的大致原理。 gcc的bounds checker基本上可以与boundschecker对应起来，都是对源代码进行修改，以达到控制内存操作功能，如malloc/free等内存管理函数、memcpy/strcpy/memset等内存读取函数和指针运算等。Valgrind则与Purify类似，都是通过对目标代码进行修改，来达到同样的目的。 Valgrind对可执行文件进行修改，所以不需要重新编译程序。但它并不是在执行前对可执行文件和所有相关的共享库进行一次性修改，而是和应用程序在同一个进程中运行，动态的修改即将执行的下一段代码。 Valgrind是插件式设计的。Core部分负责对应用程序的整体控制，并把即将修改的代码，转换成一种中间格式，这种格式类似于RISC指令，然后把中间代码传给插件。插件根据要求对中间代码修改，然后把修改后的结果交给core。core接下来把修改后的中间代码转换成原始的x86指令，并执行它。由此可见，无论是boundschecker、purify、gcc的bounds checker，还是Valgrind，修改源代码也罢，修改二进制也罢，都是代码进行修改。究竟要修改什么，修改成什么样子呢？别急，下面我们就要来介绍： 管理所有内存块。无论是堆、栈还是全局变量，只要有指针引用它，它就被记录到一个全局表中。记录的信息包括内存块的起始地址和大小等。要做到这一点并不难：对于在堆里分配的动态内存，可以通过重载内存管理函数来实现。对于全局变量等静态内存，可以从符号表中得到这些信息。 拦截所有的指针计算。对于指针进行乘除等运算通常意义不大，最常见运算是对指针加减一个偏移量，如++p、p=p+n、p=a[n]等。所有这些有意义的指针操作，都要受到检查。不再是由一条简单的汇编指令来完成，而是由一个函数来完成。有了以上两点保证，要检查内存错误就非常容易了：比如要检查++p是否有效，首先在全局表中查找p指向的内存块，如果没有找到，说明p是野指针。如果找到了，再检查p+1是否在这块内存范围内，如果不是，那就是越界访问，否则是正常的了。怎么样，简单吧，无论是全局内存、堆还是栈，无论是读还是写，无一能够逃过出工具的法眼。代码赏析(源于tcc)：对指针运算进行检查： void *__bound_ptr_add(void *p, int offset) { unsigned long addr = (unsigned long)p; BoundEntry *e; #if defined(BOUND_DEBUG) printf("add: 0x%x %d/n", (int)p, offset); #endif e = __bound_t1[addr >> (BOUND_T2_BITS + BOUND_T3_BITS)]; e = (BoundEntry *)((char *)e + ((addr >> (BOUND_T3_BITS - BOUND_E_BITS)) & ((BOUND_T2_SIZE - 1) BOUND_E_BITS))); addr -= e->start; if (addr > e->size) { e = __bound_find_region(e, p); addr = (unsigned long)p - e->start; } addr += offset; if (addr > e->size) return INVALID_POINTER; /* return an invalid pointer */ return p + offset; } static void __bound_check(const void *p, size_t size) { if (size == 0) return; p = __bound_ptr_add((void *)p, size); if (p == INVALID_POINTER) bound_error("invalid pointer"); } 重载内存管理函数： void *__bound_malloc(size_t size, const void *caller) { void *ptr; /* we allocate one more byte to ensure the regions will be separated by at least one byte. With the glibc malloc, it may be in fact not necessary */ ptr = libc_malloc(size + 1); if (!ptr) return NULL; __bound_new_region(ptr, size); return ptr; } void __bound_free(void *ptr, const void *caller) { if (ptr == NULL) return; if (__bound_delete_region(ptr) != 0) bound_error("freeing invalid region"); libc_free(ptr); } 重载内存操作函数： void *__bound_memcpy(void *dst, const void *src, size_t size) { __bound_check(dst, size); __bound_check(src, size); /* check also region overlap */ if (src >= dst && src dst + size) bound_error("overlapping regions in memcpy()"); return memcpy(dst, src, size); }