如何释放 GSettings 使用的资源？
How to release resources used by GSettings?
我正在尝试在 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
根据评论中的要求，我发布了 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 那么它显然会泄漏和崩溃。
这是 100.000 和 1.000.000 次迭代的 valgrind 输出查找此代码段的方式。
迭代次数 = 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)
这让我知道第二个代码的分配数量与释放数量几乎相同（两种情况下的差异都小于 2000，这可能是库生命周期的一些静态分配）。
在我使用 GSettings 对象的第一个片段中情况并非如此。分配与释放的数量在任何地方都不是恒定的，并且会随着时间的推移而增长。
当我可以访问一些滚动发行版（可能是 arch）时，我将针对最新的 glib 尝试 运行 这个程序，因为我认为编译最新的 glib 并插入它Ubuntu 对我来说太复杂了。
这种可访问内存的“泄漏”是您的测试程序造成的。每次构造一个GSettings对象时，都需要给D-Bus会话总线添加一些匹配规则，这样它才能接收来自dconf守护进程的信号。添加匹配规则意味着向消息总线守护程序发送 D-Bus 方法调用，然后等待回复。
通过连续创建 100000 个 GSettings 个对象，您将排队 100000 个 AddMatch 对消息总线守护程序的调用，包括 100000 个包含有关未决方法调用回复信息的分配。但是，您的程序在消息总线守护程序回复大多数 AddMatch 调用之前退出；所以很多详细说明未决答复的分配仍然在退出时分配。
如果您的程序要休眠一分钟，直到消息总线守护程序回复所有 AddMatch 调用，我希望“仍可访问”分配与 GFile比如你运行.
（请注意，可以在 main() 函数中执行 usleep() 调用来演示这一点，因为 D-Bus 方法调用和回复是在单独的工作线程中处理的。）
我正在尝试在 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
根据评论中的要求，我发布了 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 那么它显然会泄漏和崩溃。
这是 100.000 和 1.000.000 次迭代的 valgrind 输出查找此代码段的方式。
迭代次数 = 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)
这让我知道第二个代码的分配数量与释放数量几乎相同（两种情况下的差异都小于 2000，这可能是库生命周期的一些静态分配）。
在我使用 GSettings 对象的第一个片段中情况并非如此。分配与释放的数量在任何地方都不是恒定的，并且会随着时间的推移而增长。
当我可以访问一些滚动发行版（可能是 arch）时，我将针对最新的 glib 尝试 运行 这个程序，因为我认为编译最新的 glib 并插入它Ubuntu 对我来说太复杂了。
这种可访问内存的“泄漏”是您的测试程序造成的。每次构造一个GSettings对象时，都需要给D-Bus会话总线添加一些匹配规则，这样它才能接收来自dconf守护进程的信号。添加匹配规则意味着向消息总线守护程序发送 D-Bus 方法调用，然后等待回复。
通过连续创建 100000 个 GSettings 个对象，您将排队 100000 个 AddMatch 对消息总线守护程序的调用，包括 100000 个包含有关未决方法调用回复信息的分配。但是，您的程序在消息总线守护程序回复大多数 AddMatch 调用之前退出；所以很多详细说明未决答复的分配仍然在退出时分配。
如果您的程序要休眠一分钟，直到消息总线守护程序回复所有 AddMatch 调用，我希望“仍可访问”分配与 GFile比如你运行.
（请注意，可以在 main() 函数中执行 usleep() 调用来演示这一点，因为 D-Bus 方法调用和回复是在单独的工作线程中处理的。）