glib2实际上是否通过ALWAYS-MALLOC泄漏内存？
这个问题与其他许多问题不重复，因为我确实使用了G_DEBUG=gc-friendly和G_SLICE=always-malloc这是源代码：
#include int main (int argc, char *argv[]) { GHashTable *ht; ht=g_hash_table_new(g_str_hash,g_str_equal); g_hash_table_insert(ht,"foo","bar"); g_hash_table_destroy(ht); return 0; }
以下是valgrind在此代码上的输出：
# G_DEBUG=gc-friendly G_SLICE=always-malloc valgrind --leak-check=full --show-reachable=yes ./test_vg ==1880== Memcheck, a memory error detector ==1880== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==1880== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info ==1880== Command: ./test_vg ==1880== ==1880== ==1880== HEAP SUMMARY: ==1880== in use at exit: 1,260 bytes in 3 blocks ==1880== total heap usage: 5 allocs, 2 frees, 1,524 bytes allocated ==1880== ==1880== 252 bytes in 1 blocks are still reachable in loss record 1 of 3 ==1880== at 0x4A04A28: calloc (vg_replace_malloc.c:467) ==1880== by 0x35C8241707: g_malloc0 (in /lib64/libglib-2.0.so.0.2200.5) ==1880== by 0x35C8255742: ??? (in /lib64/libglib-2.0.so.0.2200.5) ==1880== by 0x35C825669D: g_slice_alloc (in /lib64/libglib-2.0.so.0.2200.5) ==1880== by 0x35C822B1D2: g_hash_table_new_full (in /lib64/libglib-2.0.so.0.2200.5) ==1880== by 0x400671: main (in /home/data/test_vg) ==1880== ==1880== 504 bytes in 1 blocks are still reachable in loss record 2 of 3 ==1880== at 0x4A04A28: calloc (vg_replace_malloc.c:467) ==1880== by 0x35C8241707: g_malloc0 (in /lib64/libglib-2.0.so.0.2200.5) ==1880== by 0x35C8255722: ??? (in /lib64/libglib-2.0.so.0.2200.5) ==1880== by 0x35C825669D: g_slice_alloc (in /lib64/libglib-2.0.so.0.2200.5) ==1880== by 0x35C822B1D2: g_hash_table_new_full (in /lib64/libglib-2.0.so.0.2200.5) ==1880== by 0x400671: main (in /home/data/test_vg) ==1880== ==1880== 504 bytes in 1 blocks are still reachable in loss record 3 of 3 ==1880== at 0x4A04A28: calloc (vg_replace_malloc.c:467) ==1880== by 0x35C8241707: g_malloc0 (in /lib64/libglib-2.0.so.0.2200.5) ==1880== by 0x35C825578B: ??? (in /lib64/libglib-2.0.so.0.2200.5) ==1880== by 0x35C825669D: g_slice_alloc (in /lib64/libglib-2.0.so.0.2200.5) ==1880== by 0x35C822B1D2: g_hash_table_new_full (in /lib64/libglib-2.0.so.0.2200.5) ==1880== by 0x400671: main (in /home/data/test_vg) ==1880== ==1880== LEAK SUMMARY: ==1880== definitely lost: 0 bytes in 0 blocks ==1880== indirectly lost: 0 bytes in 0 blocks ==1880== possibly lost: 0 bytes in 0 blocks ==1880== still reachable: 1,260 bytes in 3 blocks ==1880== suppressed: 0 bytes in 0 blocks ==1880== ==1880== For counts of detected and suppressed errors, rerun with: -v ==1880== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6)
这是内存泄漏吗？
使用Valgrind检查GLIB2程序时，我总是遇到很多错误和无法访问的项目。 在您的情况下，泄漏似乎来自哈希表的创建。 我会创建第二个哈希表，看看你是否得到了额外的块（否则，它可能是glib中的一些内部初始化）。
有关使用Valgrind与GLIB和GTK的一些注意事项，请访问wiki.gnome.org
回答你的问题：不，这不是传统意义上的内存泄漏。 你的代码很好。
即使您使用G_DEBUG=gc-friendly和G_SLICE=always-malloc ，GLib G_DEBUG=gc-friendly在退出时始终保留“仍可访问”的内存。 不要使用--show-reachable=yes选项，否则在使用GLib时总是会有污染的Valgrind输出。 但是，如果您为静态或全局变量（“仍可访问”内存）保留指针的内存，请务必小心。 在这种情况下，您最终可能会忽略自己的“真实”泄漏。