2016-07-25 114 views
2

我只是寫了這個示例程序,看看如何將一個單向鏈表如何釋放內存使用glib函數列表項

我試圖釋放內存上使用巧舌如簧的功能,但它表明,零釋放..in下面的背景下..

當使用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$ 

回答

1

你將永遠不會得到valgrind上能說會道的內存使用情況如實報告,除非你找到並安裝油嘴的具體排除的文件,告訴valgrind什麼內存glib負責,哪些不考慮報告時使用。爲什麼? Glib爲它自己的使用分配了相當多的內存,以及組成該工具包的所有列表的內存。該內存不在valgrind正常報告的範圍之內。 Glib不是唯一包含valgrind問題的軟件包,Mac OS一直不能很好地播放它。

爲此,人們(通常是glib開發人員)將編寫排除列表來解決與valgrind有關的內存報告問題。可能有多個列表需要,它必須匹配你的glib發行版,否則它將毫無價值。因此,搜索valgrind glib排除文件以匹配您的版本,並希望再次具有零均值零。