释放内存问题

grizzly

看了一下netbsd的cat代码，产生了一个问题，居然不释放分配的内存。

http://cvsweb.netbsd.org/bsdweb. ... cat.c?annotate=1.46

301行。但是有趣的事情是当把类似的代码弄到linux中，用valgrind检查内存泄漏：结果是"still reachable"。
（means your program is probably ok -- it didn't free some memory it could have. This is quite common and often reasonable. Don't use --show-reachable=yes if you don't want to see these reports.）

如果去掉static，用valgrind检查内存泄漏：结果是"definitely lost"。

（1）原始代码中实际上可以释放内存，为什么不释放呢？
（2）static有什么原因能够使得检查内存泄漏出现不同结果呢（假设valgrind是有道理的）？

谢过先。

yecheng_110

这个程序运行一下就结束了
进程结束资源就被操作系统回收可
所以没有什么内存泄漏

grizzly

楼上的意思是但凡不是什么守护进程、服务进程，这样不属于内存泄漏。对于操作系统而言，没有什么内存泄漏可言：就算程序crash了，系统还是能够管理内存分配和使用的。内存泄漏只对进程，那些不停从地址空间申请内存、又不释放不用内存进程而言。是这样吗？

mymtom

用了static后，buf 的初始值为NULL, 只会进行一次free，而且buf一直保存这malloc返回的结果。
如果去掉static, buf的初始只每次进入函数的时候都是不确定的，有可能多次malloc

思一克

是的.

对于运行一次结束的程序, 比如一个处理连接的进程, 不需要释放.

原帖由 grizzly 于 2007-12-14 00:30 发表
楼上的意思是但凡不是什么守护进程、服务进程，这样不属于内存泄漏。对于操作系统而言，没有什么内存泄漏可言：就算程序crash了，系统还是能够管理内存分配和使用的。内存泄漏只对进程，那些不停从地址空间申请 ...

grizzly

谢谢，清楚了。

Sorehead

原帖由 grizzly 于 2007-12-14 00:30 发表
楼上的意思是但凡不是什么守护进程、服务进程，这样不属于内存泄漏。

这样应该还是属于内存泄漏，只是程序执行一下就结束了，操作系统会料理后事，所以没有什么影响而已。

最好还是养成好的编程习惯。

mailt

原帖由 Sorehead 于 2007-12-14 10:45 发表


这样应该还是属于内存泄漏，只是程序执行一下就结束了，操作系统会料理后事，所以没有什么影响而已。

最好还是养成好的编程习惯。

但是我觉得这样的设计还是很有道理的。因为buf的大小是固定的，假如每次使用都malloc/free，那么当一次cat很多文件的时候，就会很无谓地多次malloc/free；采用源码中的方法，就只需要一次malloc，free由操作系统料理。即使cat是一个守候进程，这样做也不会有什么不妥当，因为它不会每处理一个文件就malloc一次buf，而保证了最多只malloc一次，只不过它不关心程序终止的时候的free的问题。

grizzly

的确，良好的编程习惯是很重要的。显然，这个例子不是初学的范例。但是，我觉得还有一点更重要，就是知道为什么需要这样的习惯。这段程序不仅存在于netbsd中。我问这个问题是因为我想知道什么时候那个”条款“可以不遵守。