FreeBSD系统下有没有检查内存泄漏的工具

zzbwang

以前在LINUX下用过ValGrind，感觉不错，在BSD上有没有类似的软件啊。
我在程序中释放了内存，用top命令看到的程序使用的内存一直不下降，是不是top命令统计的有问题？

多谢！

雨丝风片

原帖由 zzbwang 于 2006-2-21 10:30 发表
以前在LINUX下用过ValGrind，感觉不错，在BSD上有没有类似的软件啊。
我在程序中释放了内存，用top命令看到的程序使用的内存一直不下降，是不是top命令统计的有问题？

多谢！

我没用过这些工具。不过在FreeBSD的网站上可以看到很多的这样的软件：

http://www.freebsd.org/ports/devel.html

比如：

boehm-gc-6.6_2
Garbage collection and memory leak detection for C and C++
Long description | Package | Sources | Main Web Site
Maintained by: nobutaka@FreeBSD.org
Requires: libtool-1.3.5_2

ccmalloc-0.4.0_1
C/C++ memory profiler and memory leak tracer
Long description | Package | Sources | Main Web Site
Maintained by: ports@FreeBSD.org
Requires: expat-2.0.0, gettext-0.14.5_1, gmake-3.80_2, libiconv-1.9.2_1

leaktracer-2.4
Trace and analyze memory leaks in C++ programs
Long description | Package | Sources | Main Web Site
Maintained by: danfe@FreeBSD.org
Requires: expat-2.0.0, gettext-0.14.5_1, gmake-3.80_2, libiconv-1.9.2_1

zzbwang

多谢！我试试

雨丝风片

原帖由 zzbwang 于 2006-2-21 10:30 发表
我在程序中释放了内存，用top命令看到的程序使用的内存一直不下降，是不是top命令统计的有问题？

原帖由 LHA 于 2006-2-22 09:17 发表
我也发现这个问题 不太明白为什么

不知道你们指的是top命令输出中的那个指标？

【FreeBSD handbook】：

top(1) also defaults to showing you the amount of memory space taken by the process. This is split into two columns, one for total size, and one for resident size--total size is how much memory the application has needed, and the resident size is how much it is actually using at the moment.

zzbwang

在top的输出中有两个值指示程序使用的内存,一个是SIZE,另一个是RES,这两个值的具体含义不太清楚,看manual后说RES是程序驻留内存的大小,不明白.如果没有使用swap的话,程序的所有代码和数据都应该在内存中,为什么两个值不同?

gvim

SIZE是进程process的大小，包括代码段，数据段，堆栈段的大小。
RES是进程驻留的尺寸，由于程序的局部特性，和换页机制的存在，没必要将所有代码、数据加载入内存。如果SIZE说明的是全集的话，RES就说的是当前程序运行时需要的子集。
SIZE>=RES

assiss

由于标准库以及其它一些函数库（比如GTK）的实现问题，malloc分配的内存被free之后，进程并不一定会立即还给系统，而是维护一个内存池，以便下次快速分配。

这是我在别的地方看到的。标准库的实现代码还没有看，GTK的确是这样的。
所以你用TOP看的时候，很多时候并不准。必须要用特定的工具。

雨丝风片

原帖由 assiss 于 2006-3-6 13:06 发表
由于标准库以及其它一些函数库（比如GTK）的实现问题，malloc分配的内存被free之后，进程并不一定会立即还给系统，而是维护一个内存池，以便下次快速分配。

这是我在别的地方看到的。标准库的实现代码还没有看 ...

在【Linux内核源代码情景分析】中有以下一段话，觉得放在这里比较合适，

尽管“可见度”不高，brk()也许是最常使用的系统调用了，用户进程通过它向内核申请空间。人们常常并不意识到在调用brk()，原因在于很少有人会直接使用系统调用brk()向系统申请空间，而总是通过像malloc()一类的c语言库函数（或语言成分，如c++中的new）间接地用到brk()。如果把malloc()想象成零售，brk()则是批发。库函数malloc()为用户进程（malloc本身就是该进程地一部分）维持一个小仓库，当进程需要使用更多的内存空间时就像小仓库要，小仓库中存量不足时就通过brk()向内核批发。

gvim

top不是讨论OS是否归还mem的问题吧？
SIZE和RES关联的都是每一个进程本身，也就是说SIZE就是进程的所有段的大小，RES就是程序当前驻留在内存中的大小。
至于操作系统归还mem对RES是否有影响，top的RES应该看不出来。RES <= (RES+缓存保留的) <= SIZE
当 "缓存保留" = 0 时，此时mem完全归还OS；"缓存保留" = SIZE-RES时，此时mem完全缓存在buffer里。
个人理解，嘿嘿。