我有一个程序,当我从键盘输入错误数据时,它会以exit(1)
.
我正在使用 Valgrind 进行测试,虽然发生这种情况没有错误,但我可以看到仍然有可到达的 x 字节。
所以我的问题是:是程序员在点击之前释放内存exit()
还是操作系统会处理它?
这是一个好主意(在足够旧的 Windows 版本中,这是必不可少的),但是当一个程序exit()
在现代操作系统上运行时,它的整个地址空间都会被回收。
最后,操作系统会处理它(在每个现代操作系统上,旧版本的 Windows 都不是这样)。当程序终止时,您的程序使用的每个资源(内存,打开的文件描述符,...)都将被操作系统回收(除了一些旨在在进程终止后继续存在的资源,主要是某种共享内存/互斥锁)。
但是,valgrind
它可以帮助您跟踪内存泄漏并报告每个可用的内存区域,以便您可以在需要时手动释放它们。
假设我们谈论的是用户空间,我认为通常可以安全地假设在 exit() 上分配内存不是错误。但是,我认为糟糕的设计是在正常执行期间达到其结束并且在退出时不释放的程序。
在退出()之前记忆是一个坏主意。free
它无缘无故地浪费时间,并且在多线程程序中,如果其他线程没有首先加入并且可能访问一些分配的内存,它实际上可能会导致错误。
“仍然可达”不是泄漏。考虑:
#include <stdlib.h>
void *a_global;
int main() {
void *a_local = malloc(10);
a_global = malloc(20);
}
gcc -g t.c && valgrind ./a.out
==12228== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==12228== Using Valgrind-3.7.0.SVN and LibVEX; rerun with -h for copyright info
==12228== Command: ./a.out
==12228==
==12228==
==12228== HEAP SUMMARY:
==12228== in use at exit: 30 bytes in 2 blocks
==12228== total heap usage: 2 allocs, 0 frees, 30 bytes allocated
==12228==
==12228== LEAK SUMMARY:
==12228== definitely lost: 10 bytes in 1 blocks
==12228== indirectly lost: 0 bytes in 0 blocks
==12228== possibly lost: 0 bytes in 0 blocks
==12228== still reachable: 20 bytes in 1 blocks
==12228== suppressed: 0 bytes in 0 blocks
在这里,当你到达出口时,a_local
已经超出了范围。没有办法释放该内存。它永远丢失了。那是泄漏。
OTOH,您可以轻松释放a_global
(您只是不应该),它是可以访问的,并且不是泄漏。