当 Valgrind 什么都不显示时发现内存泄漏答案

【问题标题】：find memory leaks when Valgrind shows nothing当 Valgrind 什么都不显示时发现内存泄漏
【发布时间】：2021-06-29 03:12:14
【问题描述】：

我正在寻找具有大量遗留背景（多线程，使用 libstdc++ 容器）的 Linux 上的 C++ 程序中的内存泄漏。这个程序是一个代理服务器，是从客户端到服务器的请求的中介。

Valgrind 已检测到一些现已修复的问题，并且仅显示。

但是进程的 RSS（如 /proc//stat 所示的常驻内存）仍然会在给定的重复刺激（每次迭代大约 9 个字节）上增长。这不是线性的，并且会大幅增长，可能是因为 lib c++ 容器会进行内存优化，而 RSS 是通过大小为 4096 字节的页面来衡量的。

由于 Valgrind 什么也没找到，我可能怀疑一些递归调用会增加堆栈或一些未使用和被遗忘的表（例如：std::list、std::map、std::string 等）不断增长。

我看到的唯一搜索方法是：

但这些都是费力和耗时的。

【问题讨论】：

如果没有关于你的代码做什么的信息，真的很难评论。如果您的代码没有内存泄漏，则可能会发生您所描述的情况，但分配和释放之间有很长的时间间隔。释放动态分配内存的库函数（operator delete()、free() 等）也很常见，不会立即将其返回给操作系统（例如，因为向操作系统释放内存，然后请求新的分配，是比跟踪和重用已由程序释放但未释放到操作系统的内存更昂贵）。
您可以使用自定义分配器对您的 stl 容器进行一些诊断
我添加了有关代码功能的信息：代理

【解决方案1】：

使用https://github.com/vmware/chap：

为此，请收集您的流程的实时核心（在运行一个小时的迭代之后），然后以该核心的路径作为唯一参数开始章节。在章节提示符下，尝试以下操作：

count used
count free
count leaked
count writable

假设 used 报告的数量明显大于 free 报告的数量，您接下来要检查的是 leaked 的数量.如果该数字不为零，则实际上在不再引用的内存意义上存在泄漏。按照 USERGUIDE.md 了解一些分析策略。

如果 leaked 的数字为 0 或不显着，但 used 的数字是您可能有一些容器增长。使用 summarize used 作为下一步。

【讨论】：