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 回答