Chinaunix

标题: FreeBSD系统下有没有检查内存泄漏的工具 [打印本页]

作者: zzbwang 时间: 2006-02-21 10:30
标题: FreeBSD系统下有没有检查内存泄漏的工具
以前在LINUX下用过ValGrind，感觉不错，在BSD上有没有类似的软件啊。
我在程序中释放了内存，用top命令看到的程序使用的内存一直不下降，是不是top命令统计的有问题？

多谢！

作者: 雨丝风片 时间: 2006-02-21 12:26

原帖由 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 时间: 2006-02-21 13:02
多谢！我试试

作者: LHA 时间: 2006-02-22 09:17
提示: 作者被禁止或删除内容自动屏蔽

作者: 雨丝风片 时间: 2006-02-24 14:57

原帖由 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 时间: 2006-03-06 11:44
在top的输出中有两个值指示程序使用的内存,一个是SIZE,另一个是RES,这两个值的具体含义不太清楚,看manual后说RES是程序驻留内存的大小,不明白.如果没有使用swap的话,程序的所有代码和数据都应该在内存中,为什么两个值不同?

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

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

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

作者: 雨丝风片 时间: 2006-03-08 09:17

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

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

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

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

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

作者: 雨丝风片 时间: 2006-03-08 13:01

原帖由 gvim 于 2006-3-8 11:20 发表
top不是讨论OS是否归还mem的问题吧？

但也许这会影响到top的输出呢？对这里面的细节我也还没弄清楚，关于进程的这些“内存尺寸”可以另外开个话题来讨论了，

我先做了两次简单的试验：

只写了一个简单的main函数：

第一次：
                        SIZE    RES
不做任何实际操作： 1168K 444K
分配20块1K的内存： 1196K 600K
释放19块内存：       1196K    600K
全部释放：          1196K 600K

第二次：

                        SIZE    RES
不作任何实际操作：    1168K 444K
分配20块10K的内存：  1416K 600K
释放19块内存：       1416K    600K
全部释放：          1240K 600K

两次试验太少了，不能看出明显的规律，只能知道，top所显示的SIZE字段的值是和malloc以及free的内存大小有关的，这里面隐约存在着一种“批发”和“零售”的关系。中间可能有若干的临界值，继续学习ing，

作者: ~~~~ 时间: 2006-03-08 13:38
提示: 作者被禁止或删除内容自动屏蔽

作者: gvim 时间: 2006-03-08 13:40
我错了，按想当然的理解去了，惭愧惭愧

作者: angeljyt 时间: 2007-04-21 09:12
这其中可能有粒度的问题吧.总不可能哪么实时.如果释放1k,系统就回收1k.内存回收操作太频繁还不是影响性能.
我是个菜鸟.管孔之见

作者: 雨丝风片 时间: 2007-04-21 10:07

原帖由 angeljyt 于 2007-4-21 09:12 发表
这其中可能有粒度的问题吧.总不可能哪么实时.如果释放1k,系统就回收1k.内存回收操作太频繁还不是影响性能.
我是个菜鸟.管孔之见

当时讨论这个帖子的时候还没有分析过FreeBSD malloc的源代码，不过就在之后不久，就有一次关于malloc的深度讨论，链接如下：

http://bbs.chinaunix.net/viewthr ... D6%C5%E4&page=1

欢迎光临 Chinaunix (http://bbs.chinaunix.net/)