如何释放 GSettings 使用的资源？

Question

我正在尝试在 C 中编写应用程序来操作 GSettings。不幸的是，我遇到了某种内存泄漏，所以我试图追踪它们。我不确定这是库错误还是我遗漏了什么。这是我想出的最小的例子，它分配内存直到崩溃。

#include <glib.h>
#include <gio/gio.h>

int main() {
    while (1) {
        GSettings *settings = g_settings_new("com.linuxmint.updates");

        g_object_unref(settings);
        //g_clear_object(&settings); // This leaks as well but seems to leak "slower"
    }

    return 0;
}

谁能解释一下为什么在这个例子中会出现内存泄漏以及如何修复它？

PS 我正在使用libglib-2.0（版本2.56.3 附带Ubuntu 18.04 LTS / Mint）。

---

编辑 1

根据 cmets 中的请求，我发布了 valgrind 输出。我正在使用命令：valgrind --tool=memcheck --leak-check=full --leak-resolution=high --num-callers=50 --show-leak-kinds=definite ./main。我已经将程序更改为有限（它循环了 100.000 次）。这是该更改参数的输出。

==16375== Memcheck, a memory error detector
==16375== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==16375== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==16375== Command: ./main
==16375== 
==16375== 
==16375== HEAP SUMMARY:
==16375==     in use at exit: 297,081,397 bytes in 5,056,358 blocks
==16375==   total heap usage: 26,147,615 allocs, 21,091,257 frees, 1,064,178,170 bytes allocated
==16375== 
==16375== LEAK SUMMARY:
==16375==    definitely lost: 0 bytes in 0 blocks
==16375==    indirectly lost: 0 bytes in 0 blocks
==16375==      possibly lost: 2,840 bytes in 27 blocks
==16375==    still reachable: 297,066,261 bytes in 5,056,238 blocks
==16375==                       of which reachable via heuristic:
==16375==                         length64           : 1,384 bytes in 28 blocks
==16375==                         newarray           : 1,808 bytes in 33 blocks
==16375==         suppressed: 0 bytes in 0 blocks
==16375== Reachable blocks (those to which a pointer was found) are not shown.
==16375== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==16375== 
==16375== For counts of detected and suppressed errors, rerun with: -v
==16375== ERROR SUMMARY: 27 errors from 27 contexts (suppressed: 0 from 0)

我不是专家，但参数still reachable 会随着循环次数的增加而增长。如果我一直使用一个变量，如何达到这些对象（或者更确切地说是结构）？我错过了什么吗？我正在尝试做这里的建议：https://developer.gnome.org/gobject/stable/gobject-memory.html

---

编辑 2

我正在深入研究这个问题。因为我不确定我的代码实际上是否正确，所以我决定将其更改为另一个 GObject，如下所示：

#include <glib.h>
#include <gio/gio.h>

int main() {
    while (1) {
        GFile *file = g_file_new_for_path ("/path/to/some/file");

        g_object_unref(file);
        //g_clear_object(&settings);
    }

    return 0;
}

我知道这不会打开任何文件，只会创建资源句柄，但这段代码会随着时间的推移不断使用内存。如果我删除unref，那么它显然会泄漏和崩溃。

这是 valgrind 输出在 100.000 和 1.000.000 次迭代中查找此 sn-p 的方式。

迭代次数 = 100.000

==13257== Memcheck, a memory error detector
==13257== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==13257== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==13257== Command: ./main
==13257== 
==13257== 
==13257== HEAP SUMMARY:
==13257==     in use at exit: 159,435 bytes in 1,975 blocks
==13257==   total heap usage: 205,209 allocs, 203,234 frees, 6,758,893 bytes allocated
==13257== 
==13257== LEAK SUMMARY:
==13257==    definitely lost: 0 bytes in 0 blocks
==13257==    indirectly lost: 0 bytes in 0 blocks
==13257==      possibly lost: 2,528 bytes in 26 blocks
==13257==    still reachable: 144,699 bytes in 1,852 blocks
==13257==                       of which reachable via heuristic:
==13257==                         length64           : 1,688 bytes in 32 blocks
==13257==                         newarray           : 1,840 bytes in 35 blocks
==13257==         suppressed: 0 bytes in 0 blocks
==13257== Rerun with --leak-check=full to see details of leaked memory
==13257== 
==13257== For counts of detected and suppressed errors, rerun with: -v
==13257== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

迭代次数 = 1.000.000

==12440== Memcheck, a memory error detector
==12440== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==12440== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==12440== Command: ./main
==12440== 
==12440== 
==12440== HEAP SUMMARY:
==12440==     in use at exit: 157,241 bytes in 1,936 blocks
==12440==   total heap usage: 2,005,339 allocs, 2,003,403 frees, 64,363,746 bytes allocated
==12440== 
==12440== LEAK SUMMARY:
==12440==    definitely lost: 0 bytes in 0 blocks
==12440==    indirectly lost: 0 bytes in 0 blocks
==12440==      possibly lost: 2,528 bytes in 26 blocks
==12440==    still reachable: 142,505 bytes in 1,813 blocks
==12440==                       of which reachable via heuristic:
==12440==                         length64           : 1,688 bytes in 32 blocks
==12440==                         newarray           : 1,840 bytes in 35 blocks
==12440==         suppressed: 0 bytes in 0 blocks
==12440== Rerun with --leak-check=full to see details of leaked memory
==12440== 
==12440== For counts of detected and suppressed errors, rerun with: -v
==12440== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

这让我知道第二个代码的分配数与空闲数几乎相同（差异在两种情况下均

在我使用GSettings 对象的第一个sn-p 中不是这种情况。分配与释放的数量并不是一成不变的，它会随着时间的推移而增长。

我将尝试在最新的glib 上运行这个程序，因为我认为编译最新的glib 并将其插入Ubuntu 对我来说太复杂了。

Answer 1

这种可访问内存的“泄漏”是您的测试程序的产物。每次构造GSettings对象时，它都需要在D-Bus会话总线中添加一些匹配规则，以便它可以接收来自dconf守护进程的信号。添加匹配规则意味着向消息总线守护进程发送 D-Bus 方法调用，然后等待回复。

通过连续创建 100000 个 GSettings 对象，您将排队 100000 个对消息总线守护程序的 AddMatch 调用，其中包括 100000 个分配，其中包含有关挂起的方法调用回复的信息。但是，您的程序在消息总线守护程序回复大多数AddMatch 调用之前退出；因此，许多详细说明待处理回复的分配仍然在退出时分配。

如果您的程序要休眠一分钟，直到消息总线守护程序回复所有 AddMatch 调用，我希望“仍然可达”分配将与您的 GFile 示例一致跑了。

（请注意，可以在 main() 函数中调用 usleep() 来演示这一点，因为 D-Bus 方法调用和回复在单独的工作线程中处理。）