如何使用 valgrind 查找内存泄漏？

Question

如何使用 valgrind 查找程序中的内存泄漏？

我正在使用 Ubuntu 10.04，并且我有一个程序 ac。

Answer 1

你可以运行：

valgrind --leak-check=full --log-file="logfile.out" -v [your_program(and its arguments)]

Answer 2

您可以在 .bashrc 文件中创建一个别名，如下所示。

alias vg='valgrind --leak-check=full -v --track-origins=yes --log-file=vg_logfile.out'

因此，每当您想要检查内存泄漏时，只需执行简单的操作即可。

vg ./<name of your executable> <command line parameters to your executable>

这将在当前目录中生成一个 Valgrind 日志文件。

Answer 3

如何运行 Valgrind

首先检查您是否安装了 Valgrind，如果没有：

sudo apt install valgrind  # Ubuntu, Debian, etc.
sudo yum install valgrind  # RHEL, CentOS, Fedora, etc.
sudo pacman -Syu valgrind  # Arch, Manjaro, Garuda, etc.
sudo pkg ins valgrind      # FreeBSD

Valgrind 很容易用于 C/C++ 代码，甚至可以用于其他代码
正确配置后的语言（对于 Python，请参阅此）。

要运行 Valgrind，请将可执行文件作为参数传递（以及任何
程序的参数）。

valgrind --leak-check=full \
         --show-leak-kinds=all \
         --track-origins=yes \
         --verbose \
         --log-file=valgrind-out.txt \
         ./executable exampleParam1

简而言之，这些标志是：

• --leak-check=full：“将详细显示每个单独的泄漏”
• --show-leak-kinds=all：显示“完整”报告中的所有“确定的、间接的、可能的、可到达的”泄漏类型。
• --track-origins=yes：优先考虑有用的输出而不是速度。这会跟踪未初始化值的起源，这对于内存错误非常有用。如果 Valgrind 慢得令人无法接受，请考虑关闭。
• --verbose：可以告诉您程序的异常行为。重复以获得更多详细信息。
• --log-file：写入文件。当输出超出终端空间时很有用。

最后，您希望看到如下所示的 Valgrind 报告：

HEAP SUMMARY:
    in use at exit: 0 bytes in 0 blocks
  total heap usage: 636 allocs, 636 frees, 25,393 bytes allocated
 
All heap blocks were freed -- no leaks are possible
 
ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

---

我有泄漏，但是在哪里？

所以，你有内存泄漏，而 Valgrind 没有说任何有意义的事情。
也许，是这样的：

5 bytes in 1 blocks are definitely lost in loss record 1 of 1
   at 0x4C29BE3: malloc (vg_replace_malloc.c:299)
   by 0x40053E: main (in /home/Peri461/Documents/executable)

让我们看看我也写的 C 代码：

#include <stdlib.h>

int main() {
    char* string = malloc(5 * sizeof(char)); //LEAK: not freed!
    return 0;
}

嗯，丢失了 5 个字节。它是怎么发生的？错误报告只是说
main 和 malloc。在较大的程序中，这会非常麻烦
追捕。 这是因为可执行文件的编译方式。我们可以
实际上可以获得有关问题所在的逐行详细信息。重新编译你的程序
带有调试标志（我在这里使用 gcc）：

gcc -o executable -std=c11 -Wall main.c         # suppose it was this at first
gcc -o executable -std=c11 -Wall -ggdb3 main.c  # add -ggdb3 to it

现在通过此调试版本，Valgrind 指向确切的代码行
分配泄漏的内存！ （措辞很重要：它可能不
确切地说是您的泄漏位置，但是泄漏了什么。痕迹可以帮助你找到
哪里。）

5 bytes in 1 blocks are definitely lost in loss record 1 of 1
   at 0x4C29BE3: malloc (vg_replace_malloc.c:299)
   by 0x40053E: main (main.c:4)

-ggdb3 在二进制文件中包含详细的调试注释，Valgrind 可以使用它为您提供更精确的信息。以这种方式编译，GCC仍将使用默认的优化级别（-O2），这将改变您的代码以提高其效率。有时，这可能会优化您想要仔细探索的代码中的段落，或者产生其他令人惊讶的结果。在这些情况下，您可能想尝试使用 -Og 标志，该标志将包含详细的调试注释并且仅使用受限制的、调试友好的优化，以便编译的二进制文件将更接近你写的内容。您可以这样做：

gcc -o executable -std=c11 -Wall -Og main.c  # add -Og

您可以在 3.10 选项中阅读有关这些和其他调试选项的信息用于在 GCC 文档中调试您的程序。有关 -Og 如何影响优化的详细信息，请参阅 3.11控制优化的选项。

---

调试内存泄漏和内存泄漏的技术错误

• 利用cppreference！它有关于 C 和 C++ 函数的丰富文档。另请考虑 www.cplusplus.com。

• 内存泄漏的一般建议：

• 如果可以的话，使用 RAII，大多数问题都会消失。

• 确保您的动态分配的内存确实被释放。

• 不要分配内存而忘记分配指针。

• 除非旧内存被释放，否则不要用新指针覆盖指针。

• 内存错误的一般建议：

• 访问并写入您确定属于您的地址和索引。记忆
  错误与泄漏不同；它们通常只是 IndexOutOfBoundsException
  类型问题。

• 释放内存后不要访问或写入内存。

• 有时，您的泄漏/错误可能会相互关联，就像 IDE 发现您尚未输入右括号一样。解决一个问题可以解决其他问题，因此寻找一个看起来不错的罪魁祸首并应用其中的一些想法：

• 列出代码中依赖于/正在依赖于
  存在内存错误的“违规”代码。跟随程序的执行
  （甚至可能在 gdb 中），并查找前置条件/​​后置条件错误。这个想法是跟踪程序的执行，同时关注分配的内存的生命周期。

• 尝试注释掉“有问题的”代码块（在合理范围内，这样你的代码
  仍然可以编译）。如果 Valgrind 错误消失，那么您就找到了它所在的位置。

• 如果其他方法都失败，请尝试查找它。 Valgrind 也有文档！

---

看看常见的泄漏和错误

注意你的指点

60 bytes in 1 blocks are definitely lost in loss record 1 of 1
   at 0x4C2BB78: realloc (vg_replace_malloc.c:785)
   by 0x4005E4: resizeArray (main.c:12)
   by 0x40062E: main (main.c:19)

和代码：

#include <stdlib.h>
#include <stdint.h>

struct _List {
    int32_t* data;
    int32_t length;
};
typedef struct _List List;

List* resizeArray(List* array) {
    int32_t* dPtr = array->data;
    dPtr = realloc(dPtr, 15 * sizeof(int32_t)); //doesn't update array->data
    return array;
}

int main() {
    List* array = calloc(1, sizeof(List));
    array->data = calloc(10, sizeof(int32_t));
    array = resizeArray(array);

    free(array->data);
    free(array);
    return 0;
}

作为一名助教，我经常看到这个错误。学生利用
局部变量并忘记更新原始指针。这里的错误是
注意到 realloc 实际上可以将分配的内存移动到其他地方
并更改指针的位置。然后我们离开resizeArray而不告诉
array->data 数组移动到的位置。

无效写入

1 errors in context 1 of 1:
Invalid write of size 1
   at 0x4005CA: main (main.c:10)
 Address 0x51f905a is 0 bytes after a block of size 26 alloc'd
   at 0x4C2B975: calloc (vg_replace_malloc.c:711)
   by 0x400593: main (main.c:5)

和代码：

#include <stdlib.h>
#include <stdint.h>

int main() {
    char* alphabet = calloc(26, sizeof(char));

    for(uint8_t i = 0; i < 26; i++) {
        *(alphabet + i) = 'A' + i;
    }
    *(alphabet + 26) = '\0'; //null-terminate the string?

    free(alphabet);
    return 0;
}

请注意，Valgrind 向我们指出了上面注释的代码行。数组
大小为 26 的索引为 [0,25]，这就是为什么 *(alphabet + 26) 无效的原因
写——这是越界的。无效写入的常见结果是
相差一的错误。查看赋值操作的左侧。

无效读取

1 errors in context 1 of 1:
Invalid read of size 1
   at 0x400602: main (main.c:9)
 Address 0x51f90ba is 0 bytes after a block of size 26 alloc'd
   at 0x4C29BE3: malloc (vg_replace_malloc.c:299)
   by 0x4005E1: main (main.c:6)

代码：

#include <stdlib.h>
#include <stdint.h>

int main() {
    char* destination = calloc(27, sizeof(char));
    char* source = malloc(26 * sizeof(char));

    for(uint8_t i = 0; i < 27; i++) {
        *(destination + i) = *(source + i); //Look at the last iteration.
    }

    free(destination);
    free(source);
    return 0;
}

Valgrind 将我们指向上面的注释行。看看这里的最后一次迭代，
即
*(目的地+26)=*(源+26);。但是，*(source + 26) 是
再次越界，与无效写入类似。无效读也是一个
差一错误的常见结果。查看作业的右侧
手术。

---

开源（U/Dys）乌托邦

我如何知道泄漏是我的？使用时如何发现泄漏
别人的代码？我发现了不属于我的泄漏；我应该做点什么吗？全部
是合法的问题。首先，2 个现实世界的例子展示了 2 类
共同的遭遇。

Jansson：一个 JSON 库

#include <jansson.h>
#include <stdio.h>

int main() {
    char* string = "{ \"key\": \"value\" }";

    json_error_t error;
    json_t* root = json_loads(string, 0, &error); //obtaining a pointer
    json_t* value = json_object_get(root, "key"); //obtaining a pointer
    printf("\"%s\" is the value field.\n", json_string_value(value)); //use value

    json_decref(value); //Do I free this pointer?
    json_decref(root);  //What about this one? Does the order matter?
    return 0;
}

这是一个简单的程序：它读取 JSON 字符串并解析它。在制作过程中，
我们使用库调用来为我们进行解析。詹森做出了必要的
动态分配，因为 JSON 可以包含其自身的嵌套结构。
然而，这并不意味着我们decref或“释放”给我们的内存
每个功能。事实上，我上面写的这段代码会抛出“无效读取”
和“无效写入”。当您删除 decref 行时，这些错误就会消失
对于值。

为什么？变量 value 在 Jansson 中被视为“借用的引用”
API。 Jansson 会为您跟踪其内存，您只需 decref
JSON 结构彼此独立。这里的教训是：
阅读文档。真的。有时很难理解，但是
他们正在告诉你为什么会发生这些事情。相反，我们有
关于此内存错误的现有问题。

SDL：图形和游戏库

#include "SDL2/SDL.h"

int main(int argc, char* argv[]) {
    if (SDL_Init(SDL_INIT_VIDEO|SDL_INIT_AUDIO) != 0) {
        SDL_Log("Unable to initialize SDL: %s", SDL_GetError());
        return 1;
    }

    SDL_Quit();
    return 0;
}

此代码？它始终为我泄漏约 212 KiB 的内存。花点时间思考一下。我们打开然后关闭 SDL。回答？没有什么问题。

乍一听可能很奇怪。说实话，图形很混乱，有时您必须接受一些泄漏作为标准库的一部分。这里的教训是：您不必消除所有内存泄漏。有时您只需要抑制泄漏因为它们是已知问题，您无能为力关于。 （这并不是我允许忽略你自己的泄密！）

虚空的答案

我如何知道泄密何时是我的？
这是。 （无论如何，99％确定）

当我使用别人的代码时，如何找到我的泄漏？
很可能其他人已经找到了它。尝试谷歌！如果失败，请使用我上面给您的技能。如果失败，并且您主要看到 API 调用，而几乎看不到您自己的堆栈跟踪，请参阅下一个问题。

我发现了不属于我的泄漏；我应该做点什么吗？
是的！大多数 API 都有报告错误和问题的方法。使用它们！帮助回馈您在项目中使用的工具！

---

进一步阅读

感谢您陪伴我这么久。我希望你已经学到了一些东西，因为我试图帮助广大的人得到这个答案。我希望您一路上问过一些问题：C 的内存分配器如何工作？内存泄漏和内存错误到底是什么？它们与段错误有何不同？ Valgrind 是如何工作的？如果您有这些，请满足您的好奇心：

• 更多关于 < code>malloc，C 的内存分配器
• 分段错误的定义
• < a href="https://en.wikipedia.org/wiki/Memory_leak" rel="noreferrer">内存泄漏的定义
• 内存访问错误的定义
• 如何Valgrind 工作吗？

Answer 4

试试这个：

valgrind --leak-check=full -v ./your_program

只要安装了 valgrind，它就会遍历您的程序并告诉您出了什么问题。它可以为您提供指示和可能发现泄漏的大概位置。如果出现段错误，请尝试通过 gdb 运行它。