同Docker镜像在不同主机运行Valgrind，一处报内存泄漏另一处无

我们使用Docker devcontainer开展开发工作，容器运行Ubuntu 22.04、gcc-11.3和valgrind-3.18.1。执行以下命令运行单元测试以检测内存泄漏：

/usr/bin/valgrind \
    -v \
    --leak-check=full \
    --show-leak-kinds=definite,indirect,possible \
    --num-callers=50 \
    --track-origins=yes \
    --error-exitcode=1 \
        /src/.build/release/utils/test/foo_unit_test

单元测试嵌入了Python环境，在测试结束时调用Py_Finalize()清理Python的内存分配：

GTEST_API_ int main(int argc, char** argv)
{
    testing::InitGoogleTest(&argc, argv);
    int res = RUN_ALL_TESTS();
    Py_Finalize();                          // clean up python allocations
    return res;
}

在基于Amazon Linux 2的AWS Workspaces工作站上运行该容器时，Valgrind未报告任何泄漏；但在运行Ubuntu 20.04的自托管CI构建服务器上，相同容器执行相同命令却报告了Python相关的可能内存泄漏：

==333== HEAP SUMMARY:
==333==     in use at exit: 647,380 bytes in 299 blocks
==333==   total heap usage: 265,491 allocs, 265,192 frees, 85,629,984 bytes allocated
...
==333== LEAK SUMMARY:
==333==    definitely lost: 0 bytes in 0 blocks
==333==    indirectly lost: 0 bytes in 0 blocks
==333==      possibly lost: 2,728 bytes in 4 blocks
==333==    still reachable: 644,652 bytes in 295 blocks
==333==         suppressed: 0 bytes in 0 blocks
==333== ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 0 from 0)

1. Valgrind通过LD_PRELOAD替换malloc等函数，同版本下为何不同主机结果不同？
2. 不使用抑制规则的情况下，如何确保内存释放避免被判定为可能泄漏？

问题1：不同主机Valgrind结果差异的原因 #

尽管容器内的Valgrind版本、依赖环境完全一致，但主机层面的多项差异会影响检测结果：

• 内核与glibc版本差异：Ubuntu 20.04主机的内核和glibc版本与Amazon Linux 2不同，glibc的malloc实现在不同版本下有细节差异，比如内存池复用策略、线程缓存处理逻辑。Valgrind通过LD_PRELOAD接管malloc，但主机glibc的底层行为差异会导致Valgrind追踪内存分配时的表现不同，某些在Amazon Linux 2上被正确识别为已释放的内存，在Ubuntu 20.04上可能被标记为"possibly lost"。
• Docker运行时配置差异：不同主机的Docker运行时（如containerd配置、安全特性启用情况）可能导致容器内进程环境存在细微区别，比如内存映射方式、进程地址空间布局，这些都会影响Valgrind对内存泄漏的判定。
• 主机内存管理特性差异：Ubuntu 20.04可能启用了部分Amazon Linux 2没有的内存优化特性，这些特性会间接影响容器内进程的内存分配行为，进而被Valgrind捕捉为不同结果。

问题2：不使用抑制规则避免"可能泄漏"的方法 #

要彻底消除Valgrind的"possibly lost"报告，需从Python初始化到清理的全流程规范操作：

• 严格配对初始化与清理：如果测试中多次调用Py_Initialize()，必须保证每次初始化都对应一次Py_Finalize()，避免Python运行时资源残留。注意Py_Finalize()无法完全释放所有Python内存（比如全局字符串缓存会被标记为"still reachable"），但"possibly lost"通常意味着存在未关联到全局根的内存块，需要针对性处理。
• 显式清理Python对象引用：在调用Py_Finalize()前，手动清理所有创建的Python对象，确保每个PyObject*都调用Py_DECREF()或Py_XDECREF()释放引用，避免循环引用或局部对象残留。可通过PyGC_Collect()强制触发垃圾回收，处理循环引用问题。
• 采用Python子解释器：若测试需多次初始化Python，优先使用子解释器（Py_NewInterpreter()）而非反复调用Py_Initialize()/Py_Finalize()，子解释器的资源能更彻底地被回收，减少残留内存。
• 检查Python集成逻辑：确保所有与Python交互的代码严格遵循内存管理规范，比如从Python API获取的对象是否正确释放，有没有遗漏的引用计数操作。

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