Как освободить память с помощью функции 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 точно сообщать о бойком использовании памяти, если не найти и установить краснобайствующие конкретные исключения файлы, которые говорят valgrind, что память glib несет ответственность и то, что не рассматривать в использовать при отчетности. Зачем? Glib выделяет довольно много памяти для собственного использования, а также для памяти для всех списков и т. Д., Которые составляют набор инструментальных средств. Эта память находится за пределами того, что обычно можно точно сообщить valgrind. Glib - это не единственный пакет, который имеет проблемы с valgrind, Mac OS не играет с ним все хорошо.

В этой связи люди, как правило, разработчики glib, напишут так называемые исключения-списки, чтобы решить проблему с памятью с помощью valgrind. Может потребоваться более одного списка, и он должен соответствовать вашему выпуску glib или он будет бесполезен. Поэтому найдите файл исключения valgrind glib в соответствии с вашей версией и, надеюсь, у него снова будет нулевой нулевой нуль.