Valgrind 为我的代码提供了以下泄漏摘要。但是,我已经释放了所有 malloc 的内存。这是一件坏事,还是正常的?我的程序在c中。
==3513== 泄漏摘要:
==3513== 肯定丢失:0 个块中的 0 个字节。
==3513== 可能丢失:0 个块中的 0 个字节。
==3513== 仍然可达:1 个块中的 568 个字节。
==3513== 抑制:0 个块中的 0 个字节。
Valgrind 为我的代码提供了以下泄漏摘要。但是,我已经释放了所有 malloc 的内存。这是一件坏事,还是正常的?我的程序在c中。
==3513== 泄漏摘要:
==3513== 肯定丢失:0 个块中的 0 个字节。
==3513== 可能丢失:0 个块中的 0 个字节。
==3513== 仍然可达:1 个块中的 568 个字节。
==3513== 抑制:0 个块中的 0 个字节。
valgrind 消息still reachable: 568 bytes in 1 blocks.
意味着在您的应用程序中释放了仍然“可访问”的内存,这意味着您在某处仍有指向它的指针。在关闭时,这可能意味着某种全局变量。但是,由于“肯定泄露”或“可能泄露”的字节数为零,因此这种情况完全是良性的。别担心。
仍然可访问的内存意味着它被全局或静态指针指向。您要做的是运行 valgrind--show-reachable=yes
以查看它是否有问题。
通常它是无害的,并且来自这样的函数:
void foo()
{
static char *buffer = 0;
if (buffer == 0)
{
buffer = (char *)malloc(...);
}
}
该 malloc 仍然可以访问。但是无论 foo 被调用多少次,你只分配一次缓冲区,所以这里不释放它并没有什么坏处。
但是考虑这样的函数:
void foo()
{
static node_t *head = 0;
node_t *node = (node_t *)malloc(sizeof(node_t));
if (node)
{
node->next = head;
head = node;
}
...
}
每次调用此函数时,都会分配另一个节点。虽然您可能只会泄漏几个节点用于测试运行,但在生产运行中,您可能会泄漏足够多的内存以致内存不足。
区分差异的一种方法是查看不同的运行是否总是泄漏相同的内存,或者泄漏更多的内存是具有更大输入的测试运行。
但同样,如果您想安全,请使用--show-reachable=yes
并查看发生了什么。
这些没有泄露,也没有什么可担心的。内存可能是由 C 库分配的。如果您真的想知道它们被分配到哪里,请使用--leak-check=full --show-reachable=yes
.
将 free()'ed 的指针归零是个好主意,这会在(错误地)尝试再次取消引用它们时导致崩溃。
如果您确定您“已释放所有 malloc'ed 内存”,那么,没有任何问题。即使您可能经常需要解决这些问题,您也不直接对来自其他方的组件中的内存泄漏负责。
来自 valgrind 的报告并没有真正提供足够的信息让我们帮助您。
我已经看到内存检查工具多次出现误报,但我对 valgrind 本身没有任何直接经验。
它会给你块的地址吗?有时您可以通过查看这 568 个字节中的数据类型来了解很多。
嗯,568 字节,大约是 MAX_PATH unicode 字符串的大小。
就个人而言,我总是忘记和检查valgrind make test
,总是添加至少几个额外的仍然可以访问的字节......确保您的应用程序直接由 valgrind 运行...... :)