3

Valgrind 为我的代码提供了以下泄漏摘要。但是，我已经释放了所有 malloc 的内存。这是一件坏事，还是正常的？我的程序在c中。

==3513== 泄漏摘要：

==3513== 肯定丢失：0 个块中的 0 个字节。

==3513== 可能丢失：0 个块中的 0 个字节。

==3513== 仍然可达：1 个块中的 568 个字节。

==3513== 抑制：0 个块中的 0 个字节。

4

7 回答 7

8

valgrind 消息still reachable: 568 bytes in 1 blocks.意味着在您的应用程序中释放了仍然“可访问”的内存，这意味着您在某处仍有指向它的指针。在关闭时，这可能意味着某种全局变量。但是，由于“肯定泄露”或“可能泄露”的字节数为零，因此这种情况完全是良性的。别担心。

于 2010-01-27T04:34:35.297 回答
6

仍然可访问的内存意味着它被全局或静态指针指向。您要做的是运行 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并查看发生了什么。

于 2010-01-27T07:26:43.223 回答
2

这些没有泄露，也没有什么可担心的。内存可能是由 C 库分配的。如果您真的想知道它们被分配到哪里，请使用--leak-check=full --show-reachable=yes.

于 2010-01-27T07:31:08.237 回答
1

将 free()'ed 的指针归零是个好主意，这会在（错误地）尝试再次取消引用它们时导致崩溃。

于 2010-01-27T07:00:33.877 回答
1

如果您确定您“已释放所有 malloc'ed 内存”，那么，没有任何问题。即使您可能经常需要解决这些问题，您也不直接对来自其他方的组件中的内存泄漏负责。

来自 valgrind 的报告并没有真正提供足够的信息让我们帮助您。

我已经看到内存检查工具多次出现误报，但我对 valgrind 本身没有任何直接经验。

于 2010-01-27T04:21:56.387 回答
1

它会给你块的地址吗？有时您可以通过查看这 568 个字节中的数据类型来了解很多。

嗯，568 字节，大约是 MAX_PATH unicode 字符串的大小。

于 2010-01-27T04:34:53.597 回答
0

就个人而言，我总是忘记和检查valgrind make test，总是添加至少几个额外的仍然可以访问的字节......确保您的应用程序直接由 valgrind 运行...... :)

于 2013-08-29T21:22:28.033 回答