是由程序员在exit()上解除分配吗?
我有一个程序,当我从键盘输入错误数据时,它只是退出exit(1)
。
我正在使用Valgrind进行测试,虽然发生这种情况但没有错误,但我可以看到仍有可达的x字节。
所以我的问题是:程序员在点击exit()
或exit()
操作系统exit()
之前是否需要释放内存?
这是一个好主意(在Windows的旧版本中,它是必不可少的),但是当一个程序exit()
在现代操作系统上时,它的整个地址空间都被回收了。
最后,操作系统会处理它(在每个现代操作系统上,旧版本的Windows都不是这样)。 当程序终止时,操作系统将回收您的程序使用的每个资源(内存,打开文件描述符……)(除了某些资源旨在使进程终止,主要是某种共享内存/互斥锁)。
但是, valgrind
可以帮助您跟踪内存泄漏并报告每个可用的内存区域,以便您可以根据需要手动释放它们。
假设我们正在谈论用户空间,我认为通常可以安全地假设在exit()上分配内存不是错误。 但是,我认为糟糕的设计是一个程序在正常执行期间到达终点并且在退出时不会释放。
在exit()之前free
内存是个坏主意。 它没有充分的理由浪费时间,并且在multithreading程序中,如果其他线程没有首先连接并且可能访问一些分配的内存,它实际上可能导致错误。
“仍然可以到达” 不是泄漏。 考虑:
#include void *a_global; int main() { void *a_local = malloc(10); a_global = malloc(20); } gcc -g tc && 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
(你不应该),它是可以访问的,而不是泄漏。