SIGKILL信号是否会引起内存泄露

一梦如是

1. 
   
2. #include <stdlib.h>
   
3. #include <unistd.h>
   
4. 
   
5. int
   
6. main(void)
   
7. {
   
8.         char *s;
   
9.         s = malloc(1);
   
10.         sleep (10);
    
11.         free(s);
    
12.         return 0;
    
13. }
    

复制代码

用valgrind检测，该程序sleep期间，若产生导致终止进程的信号，那么会产生内存泄露。
一般信号可以用信号阻塞或信号捕捉来解决。但SIGKILL呢（valgrind也无法检测SIGKILL产生后的情况，因为无法捕捉SIGKILL，产生该信号后直接终止进程），逻辑上应该也会产生内存泄露（我没有好方法证实）。如果会产生内存泄露，有什么方法可以避免或尽量避免？

isnowran

当然不会，进程结束了，资源也被回收了

bGFuZ3Vl

stack 和 heap 内存，均属于进程自己的资源

一梦如是

google仔细搜索了一下，多数观点是“内存泄露的概念限定于在进程运行期间，进程终止（无论怎么终止），则内核会负责回收该进程分配的内存资源”，但也有一些持反面意见的观点，或有认为和系统相关的，没搜到对此问题权威的证明。

使用我的代码例子，编译后生成a.out，用valgrind执行

1. valgrind ./a.out

复制代码

在sleep期间，valgrind没有继续输出，用ctrl+c递送SIGINT信号后，valgrind输出中有still reachable的块，但并不像程序代码中没有free时那样报告有definitely lost的块。这似乎暗示由于信号导致进程终止而至未显式释放内存，并非被归于内存泄露。

但我仍有疑惑，举个例子来说：一个服务器，每accept一个客户端的请求，就fork一个子进程（父进程无任何内存泄露）来处理请求，在子进程中malloc了固定的一段内存使用。那么以进程终止内核会回收内存的观点来看，子进程中有内存泄露和在子进程退出前free这段内存又有多大区别呢？客户端高并发连接的情况下，这两种情况都可能导致内存耗尽而至之后的malloc失败，直到有客户段退出、服务器相应退出该子进程释放内存（这里两种情况依然都会释放内存，前者是服务器程序主动释放，后者是内核释放）。既然子进程未终止前内存始终未释放，终止后又都会被释放，那么是否可以认为子程序中的这处内存泄露是无害的？

converse

可以动态分配的内存,如果自己不释放,进程退出的时候也会释放,但是可以分配的动态内存是有限的.

langue

原帖由 converse 于 2007-3-11 13:41 发表
可以动态分配的内存,如果自己不释放,进程退出的时候也会释放,但是可以分配的动态内存是有限的.

请问这两处的差别是……

.

一梦如是

原帖由 converse 于 2007-3-11 13:41 发表
可以动态分配的内存,如果自己不释放,进程退出的时候也会释放,但是可以分配的动态内存是有限的.

以我4楼服务器那个例子来说。子进程代码中是否free这块固定的内存，对剩余的内存大小的影响有何区别呢？高并发连接情况下，即使代码中正确free，也依然会耗尽动态内存。而没free却也不会导致子进程退出后该段动态内存无法回收。

converse

原帖由 langue 于 2007-3-11 13:45 发表


请问这两处的差别是……

.

我的意思是如果一直这么不释放下去进程的堆会被耗尽,但是进程退出的时候自己也会释放.

mik

一般系统对于系统资源（当然包括内存资源）会建立计数机制，直到引用计数为0，系统资源才会回收。

思一克

我说两点

1) 进程结束内存自动被释放. 结束前不需要自己free. 这不是什么还有讨论余地的观点, 而是定律.
2) 子进程malloc成功与否(返回指针或0)和其它子进程分配了多少内存没有关系. malloc失败只能是因为自己分配的过多引起. 和其他进程无关.  其它进程占有内存过多了, 会在malloc成功后使用获得的内寸时有反映,比如引起SWAP,速度变慢等.

原帖由 一梦如是 于 2007-3-11 13:08 发表
google仔细搜索了一下，多数观点是“内存泄露的概念限定于在进程运行期间，进程终止（无论怎么终止），则内核会负责回收该进程分配的内存资源”，但也有一些持反面意见的观点，或有认为和系统相关的，没搜到对此问 ...