C++ 代码内存泄漏

Posted 2023-02-16

【中文标题】C++ 代码内存泄漏

【英文标题】：C++ code memory leak

【发布时间】：2013-08-21 12:52:41

【问题描述】：

我在 Linux 下的 ARM CPU 硬件上执行 C++ 代码。我在硬件上运行我的二进制文件并继续监视我的进程，以查看它的内存使用量是否随着时间的推移而增长，每半小时间隔一次。

top -p pid-of-process

查看列：RES顶部输出中的内存和内存百分比

还要检查

cat /proc/pid-of-process/status 

查看字段VMRSS：这是我的进程的驻留集大小内存。

我看到 VMRSS 和 RES 内存每 1 小时不断增加数百千字节。进程只是在运行，没有测试在运行，所以它一直在做同样的事情，负载没有变化。

现在我的问题是：这是否意味着我的代码中可能存在内存泄漏。

或者这种增加是否归因于其他原因（如果有的话）？

检查是否存在内存泄漏：

我查看了代码，发现每个新的（动态内存运算符）都有相应的删除（空闲内存）

在 valgrind memcheck 上运行了整个过程，在报告中没有看到任何泄漏。我看到了

肯定丢失：0 个块中的 0 个字节

间接丢失：0 个块中的 0 个字节

可能丢失：7 个块中的 1,008 个字节

**编辑：在下面回答 arne 的评论。可能丢失的块来自 pthread_create 和更高版本的 glibc，所以不确定这是怎么回事/发生了什么？

56 个丢失记录 27 中可能丢失了 5 个块中的 720 个字节

==11151== at 0x402732C: calloc (vg_replace_malloc.c:467)

==11151== by 0x4010C34: allocate_dtv (dl-tls.c:300)

==11151== 0x40113D8：_dl_allocate_tls (dl-tls.c:464)

==11151== by 0x404746C: pthread_create@@GLIBC_2.1 (allocatestack.c:571)**

随着时间的推移，这种内存增加会是什么？如何进一步调试以找到原因？

【问题讨论】：

您是否重新检查过“可能丢失”的内存区域？它恰好等于 1k，因此每小时可能有几百 k。

valgrind 只检查“孤立”（或“废弃”）的内存。很高兴接受vector<int> v; int i=0; for(;;) v.push_back(i++); 或类似的东西。换句话说，以荒谬的方式“收集”数据的功能没有帮助。当然，如果你运气不好，这可能发生在一些帮助库中，而不是你自己的代码中。

@Mats Petersson 在对代码进行初步审查时，我认为没有使用任何 C++ STL/libstdc++ 容器，甚至以正常方式使用标准数据类型数组

@arne - 已编辑我的 OP 以回复您的评论。

@goldenmean：是的，但你可能确实有某种容器（链表、动态数组或类似的）——它不必是 STL 来“收集数据直到内存已满” .如果您的应用程序的内存在增长，则可能有一些东西正在某处“收集”数据。

【参考方案1】：

由于您找不到直接的泄漏，您似乎需要比较内存状态的快照以查看发生了什么变化。快速搜索表明valgrind的massif可以做snapshot，有python script可以比较它们（但如果你的程序很小，可能你可以手动比较）