我正在使用 Valgrind 检查我编写的 C 应用程序中的泄漏。
我正在使用第 3 方库...但我不能 100% 确定问题是否真的只出在它们身上。如果我通过我的代码运行 10 条消息，我会在 Linux 上得到以下信息:
==12460== LEAK SUMMARY:
==12460== definitely lost: 70,794 bytes in 11 blocks
==12460== indirectly lost: 0 bytes in 0 blocks
==12460== possibly lost: 69,960 bytes in 19 blocks
==12460== still reachable: 52,095 bytes in 33 blocks
==12460== suppressed: 0 bytes in 0 blocks
如果我通过我的代码运行 100 条消息，我会得到:
==12811== LEAK SUMMARY:
==12811== definitely lost: 70,794 bytes in 11 blocks
==12811== indirectly lost: 0 bytes in 0 blocks
==12811== possibly lost: 69,960 bytes in 19 blocks
==12811== still reachable: 61,795 bytes in 133 blocks
==12811== suppressed: 0 bytes in 0 blocks
所以你可以看到“仍然可达”是唯一真正增长的地方...这是否与以下事实有关:当我将此代码带到 Solaris 时，我在 PRSTAT 下看到了 SIZE 字段一段时间后成长？我认为“仍然可以访问”仍然是“某种内存泄漏”？
我的 Valgrind 日志中“仍然可以访问”的示例如下:
==12811== 848 bytes in 1 blocks are still reachable in loss record 34 of 48
==12811== at 0x4A067BA: malloc (vg_replace_malloc.c:263)
==12811== by 0x656F1A7: xppInitialize (in /opt/mqm/lib64/libmqmcs.so)
==12811== by 0x6538802: InitProcessInitialisation (in /opt/mqm/lib64/libmqmcs.so)
==12811== by 0x653A3D4: xcsInitializeEx (in /opt/mqm/lib64/libmqmcs.so)
==12811== by 0x653AF94: xcsInitialize (in /opt/mqm/lib64/libmqmcs.so)
==12811== by 0x6250BAC: zstMQCONNX (in /opt/mqm/lib64/libmqz.so)
==12811== by 0x60B1605: MQCONNX (in /opt/mqm/lib64/libmqm.so)
==12811== by 0x585CEBA: wmq_receiver_initialize (wmq_receiver.c:18)
==12811== by 0x4E10D58: wmq_receiver_proxy_initialize (wmq_receiver_proxy.c:17)
==12811== by 0x402D02: initialiseWMQReceiverProxy (test_outbound.c:296)
==12811== by 0x4027E8: outboundThreadMainLoop (test_outbound.c:209)
==12811== by 0x37EA2077E0: start_thread (in /lib64/libpthread-2.12.so)
但上面是在第 3 方 IBM 库中？但我不敢相信 IBM(对于 Websphere MQ)会在他们的库中出现泄漏，因为它已经使用了很多年......我会在这里遗漏什么吗？
有什么方法可以更好地追踪并修复这些“仍可访问”的漏洞？我想我说得对，这很可能是我在移植应用程序后在 Solaris 上看到内存逐渐增长的原因......
感谢您的帮助;-)
林顿
最佳答案
“仍然可达”通常意味着代码有一些静态(或线程本地)指针变量，它是用 malloc & Co 初始化的。这部分在第三方库中增长可能是一个表明该库确实会不时扩展其缓冲区以应对不断增长的请求。但是由于似乎没有额外的“最终丢失”，它似乎很好地做到了这一点，例如通过使用 realloc。
在你的情况下，你必须看看当你对图书馆施加压力时，这是否会进一步增加。最后你可以为那个库写一个“抑制”文件，所以 valgrind 会忽略这些。在现代 Linux 发行版上，您已经拥有一些标准库，例如
根据我个人的喜好，明确和可能丢失的部分会让我更担心，我会先清理它们。如果 valgrind 设法为您的应用程序的 every malloc 捕获 free，您只能确定根本没有泄漏。
关于c - "still reachable"VALGRIND 内存泄漏 (Linux) 是否与 SOLARIS 上的 PRSTAT 内存增长有关？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/8366172/