如何使用 glib 函数为列表项释放内存

Question

我刚刚写了这个示例程序来看看如何在单链表上使用 glib 函数

我试图释放内存，但它显示零释放..在下面的上下文中..

使用g_free(list) 时显示一个空闲，但使用 valgrind 时显示无效空闲..

valgrind 时如何释放内存而不出现任何错误？

谢谢

  1   #include<headers.h>
  2   int main()
  3       {
  4             printf("SINGLY LINKED LIST\n");
  5
  6             GSList *list = NULL,*iterator = NULL;
  7
  8             list = g_slist_append(list,"First_Element");
  9             printf("1st--%p\n",list);
 10
 11             list = g_slist_prepend(list,"Zeroth_Element");
 12             printf("0th--%p\n",list);
 13
 14             list = g_slist_append(list,"second_element");
 15             printf("2nd--%p\n",list);
 16
 17             for(iterator = list;iterator;iterator = iterator->next)
 18                     printf("%s\n",(char*)iterator->data);
 19
 20             g_slist_free(list);
 21     return 0;
 22     }

bash-4.1$ valgrind --leak-check=full --show-reachable=yes ../bin/exe
==8021== Memcheck, a memory error detector
==8021== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==8021== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==8021== Command: ../bin/exe
==8021==
SINGLY LINKED LIST
1st--0x58fff00
0th--0x58fff10
2nd--0x58fff10
Zeroth_Element
First_Element
second_element
==8021==
==8021== HEAP SUMMARY:
==8021==     in use at exit: 4,252 bytes in 8 blocks
==8021==   total heap usage: 8 allocs, 0 frees, 4,252 bytes allocated
==8021==
==8021== 240 bytes in 1 blocks are possibly lost in loss record 1 of 6
==8021==    at 0x4C26588: memalign (vg_replace_malloc.c:727)
==8021==    by 0x4C26623: posix_memalign (vg_replace_malloc.c:876)
==8021==    by 0x4E8D777: ??? (in /lib64/libglib-2.0.so.0.2800.8)
==8021==    by 0x4E8DFFB: g_slice_alloc (in /lib64/libglib-2.0.so.0.2800.8)
==8021==    by 0x4E8F612: g_slist_append (in /lib64/libglib-2.0.so.0.2800.8)
==8021==    by 0x400666: main (ex_main.c:8)
==8021==
==8021== 252 bytes in 1 blocks are still reachable in loss record 2 of 6
==8021==    at 0x4C267BB: calloc (vg_replace_malloc.c:593)
==8021==    by 0x4E78BF7: g_malloc0 (in /lib64/libglib-2.0.so.0.2800.8)
==8021==    by 0x4E8CFD1: ??? (in /lib64/libglib-2.0.so.0.2800.8)
==8021==    by 0x4E8DE8D: g_slice_alloc (in /lib64/libglib-2.0.so.0.2800.8)
==8021==    by 0x4E8F612: g_slist_append (in /lib64/libglib-2.0.so.0.2800.8)
==8021==    by 0x400666: main (ex_main.c:8)
==8021==
==8021== 504 bytes in 1 blocks are still reachable in loss record 3 of 6
==8021==    at 0x4C267BB: calloc (vg_replace_malloc.c:593)
==8021==    by 0x4E78BF7: g_malloc0 (in /lib64/libglib-2.0.so.0.2800.8)
==8021==    by 0x4E8CFF1: ??? (in /lib64/libglib-2.0.so.0.2800.8)
==8021==    by 0x4E8DE8D: g_slice_alloc (in /lib64/libglib-2.0.so.0.2800.8)
==8021==    by 0x4E8F612: g_slist_append (in /lib64/libglib-2.0.so.0.2800.8)
==8021==    by 0x400666: main (ex_main.c:8)
==8021==
==8021== 504 bytes in 1 blocks are still reachable in loss record 4 of 6
==8021==    at 0x4C267BB: calloc (vg_replace_malloc.c:593)
==8021==    by 0x4E78BF7: g_malloc0 (in /lib64/libglib-2.0.so.0.2800.8)
==8021==    by 0x4E8D011: ??? (in /lib64/libglib-2.0.so.0.2800.8)
==8021==    by 0x4E8DE8D: g_slice_alloc (in /lib64/libglib-2.0.so.0.2800.8)
==8021==    by 0x4E8F612: g_slist_append (in /lib64/libglib-2.0.so.0.2800.8)
==8021==    by 0x400666: main (ex_main.c:8)
==8021==
==8021== 720 bytes in 3 blocks are possibly lost in loss record 5 of 6
==8021==    at 0x4C26588: memalign (vg_replace_malloc.c:727)
==8021==    by 0x4C26623: posix_memalign (vg_replace_malloc.c:876)
==8021==    by 0x4E8D777: ??? (in /lib64/libglib-2.0.so.0.2800.8)
==8021==    by 0x4E8E031: g_slice_alloc (in /lib64/libglib-2.0.so.0.2800.8)
==8021==    by 0x4E8F612: g_slist_append (in /lib64/libglib-2.0.so.0.2800.8)
==8021==    by 0x400666: main (ex_main.c:8)
==8021==
==8021== 2,032 bytes in 1 blocks are still reachable in loss record 6 of 6
==8021==    at 0x4C267BB: calloc (vg_replace_malloc.c:593)
==8021==    by 0x4E78BF7: g_malloc0 (in /lib64/libglib-2.0.so.0.2800.8)
==8021==    by 0x4E8DE32: g_slice_alloc (in /lib64/libglib-2.0.so.0.2800.8)
==8021==    by 0x4E8F612: g_slist_append (in /lib64/libglib-2.0.so.0.2800.8)
==8021==    by 0x400666: main (ex_main.c:8)
==8021==
==8021== LEAK SUMMARY:
==8021==    definitely lost: 0 bytes in 0 blocks
==8021==    indirectly lost: 0 bytes in 0 blocks
==8021==      possibly lost: 960 bytes in 4 blocks
==8021==    still reachable: 3,292 bytes in 4 blocks
==8021==         suppressed: 0 bytes in 0 blocks
==8021==
==8021== For counts of detected and suppressed errors, rerun with: -v
==8021== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 6 from 6)
bash-4.1$

Answer 1

你永远不会让valgrind 准确报告 glib 内存使用情况，除非你找到并安装了 glib 特定的排除文件，这些文件告诉valgrind glib 负责哪些内存以及在报告时不考虑使用哪些内容。为什么？ Glib 分配了相当多的内存供自己使用，以及用于构成工具包的所有列表等的内存。此内存超出了valgrind 通常可以准确报告的范围。 Glib 不是唯一一个与 valgrind 存在问题的软件包，Mac OS 并不能一直很好地使用它。

为此，人们，通常是 glib 开发人员，将编写所谓的 exclusion-lists 来解决 valgrind 的内存报告问题。可能需要多个列表，并且它必须与您的 glib 版本相匹配，否则它将一文不值。因此，请搜索 valgrind glib 排除文件 以匹配您的版本，并希望这将再次为零均值。