删除所有动态内存后valgrind仍提示内存泄漏错误如何排查

1. 你的代码无手动内存泄漏 #

你代码中两处动态内存申请（main函数里的ip_ptr_array、algo_fun函数里的local数组）都已经通过delete[]正确释放，没有你编写的业务代码导致的内存泄漏问题。

2. valgrind 输出字段说明 #

valgrind 的泄漏报告每个字段含义如下：

• definitely lost：明确泄漏，程序退出时没有任何指针指向这块动态内存，完全没有释放的可能性，属于必须修复的问题
• indirectly lost：间接泄漏，通常出现在嵌套动态内存申请的场景，比如你申请了一个包含指针成员的类对象，对象的指针成员也申请了动态内存，你只释放了类对象却没有释放成员指向的内存，也属于必须修复的问题
• possibly lost：可能泄漏，valgrind 无法确定是否还有有效指针指向这块内存，大部分场景是指针偏移到了动态内存的中间位置而非起始地址，建议逐一排查
• still reachable：仍可访问，程序退出时还有有效指针指向这块内存，只是程序没有主动调用释放逻辑。你遇到的72704字节的still reachable属于标准库的全局预分配内存（比如iostream底层缓冲、glibc堆预分配），不属于用户代码的问题，不需要处理
• suppressed：已屏蔽，是系统底层库已知的不影响运行的微小泄漏，valgrind 默认会屏蔽这类报告，不需要处理

你贴出的报告中三类需要修复的泄漏数值都是0，错误总数也是0，说明你的代码内存管理完全符合要求，不需要额外修改。

3. 通用内存泄漏排查方法 #

• 排查时优先处理definitely lost、indirectly lost、possibly lost三类报告，still reachable和suppressed默认无需处理
• 编译代码时添加-g参数保留调试符号，valgrind才能输出具体的代码行号，方便定位问题
• 如果需要定位泄漏的内存申请位置，可以在valgrind运行参数中添加--track-origins=yes，可以直接显示对应内存是在哪一行代码申请的
• 手动管理内存时建议遵循「谁申请谁释放」的原则，如果函数内部申请内存返回给调用者使用，一定要明确标注调用者需要负责释放该内存，避免漏释放

内容的提问来源于stack exchange，提问作者karim