C ++空程序内存泄漏

问题描述

考虑以下代码

int main(){
    return 0;
}

我用g ++编译了它，并将输出传递给valgrind.输出如下.

I compiled it with g++ and passed the output to valgrind. The output is the following.

==11752== HEAP SUMMARY:
==11752==     in use at exit: 72,704 bytes in 1 blocks
==11752==   total heap usage: 1 allocs, 0 frees, 72,704 bytes allocated
==11752==
==11965== LEAK SUMMARY:
==11965==    definitely lost: 0 bytes in 0 blocks
==11965==    indirectly lost: 0 bytes in 0 blocks
==11965==      possibly lost: 0 bytes in 0 blocks
==11965==    still reachable: 72,704 bytes in 1 blocks
==11965==         suppressed: 0 bytes in 0 blocks

但是，用gcc在C语言中编译相同的代码会产生以下valgrind输出:

However, compiling the same code in C with gcc produces this valgrind output:

==11771== HEAP SUMMARY:
==11771==     in use at exit: 0 bytes in 0 blocks
==11771==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==11771==
==11771== All heap blocks were freed -- no leaks are possible

看起来像编译

似乎空的C ++程序实际上分配了内存并没有释放它(这不是灾难，因为它是仍然可以到达"的泄漏)，我不知道为什么会这样.

It looks like the empty C++ program actually allocates memory and does not free it (it's not a disaster since it's a "still reachable" leak), and I have no clue why this is happening.

我在具有g ++ 6.3的linux(solus os)上进行了此测试.

I did this test on linux (solus os) with g++ 6.3.

有人可以解释发生了什么事吗?

Can someone explain what's going on ?

推荐答案

这甚至不是泄漏.对于程序来说，极端是不释放某些全局变量指向的内存块的.进行 free 的操作是

It's not even a leak. It is extremely common for programs to not free a block of memory that some global points to; doing the freeing is

• 不必要的工作，只会使程序退出速度变慢
• 如果有多个线程正在运行，可能会导致并发症(退出线程可能会使地毯从另一个线程的下方拉出)
• 如果清理的其他部分可以访问此块等，则可能导致复杂化.

要获取线索，请运行 valgrind --leak-check = full --show-reachable = yes ... .这样会告诉您该块的分配位置.

To get a clue, run valgrind --leak-check=full --show-reachable=yes .... That will tell you where the block was allocated.

这篇关于C ++空程序内存泄漏的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！