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

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

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

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

1 个答案: