巧舌如簧：Valgrind的报告“仍可达” g_strsplit

之后块我有一个非常简单的代码：巧舌如簧：Valgrind的报告“仍可达” g_strsplit

#include <stdio.h> 
#include <glib.h> 

int main(int argc, char * argv[]) 
{ 
    const char * path = "https://stackoverflow.com/a/b/c/d/e/f/g/h/"; 
    gchar ** parts = NULL; 
    int i; 

    parts = g_strsplit((const gchar *) path, "/", 0); 

    for (i = 0; parts[i]; i++) { 
    if (parts[i][0] == '\0') { 
     continue; 
    } 
    printf("part: %s\n", parts[i]); 
    } 

    g_strfreev(parts); 
    return 0; 
}

然而，当我运行通过Valgrind的这段代码，我得到了一堆“仍可达”块：

==12924== 
==12924== HEAP SUMMARY: 
==12924==  in use at exit: 4,252 bytes in 8 blocks 
==12924== total heap usage: 19 allocs, 11 frees, 4,358 bytes allocated 
==12924== 
==12924== 240 bytes in 1 blocks are still reachable in loss record 1 of 6 
==12924== at 0x4A04820: memalign (vg_replace_malloc.c:581) 
==12924== by 0x4A048D7: posix_memalign (vg_replace_malloc.c:709) 
==12924== by 0x36A8255F87: ??? (in /lib64/libglib-2.0.so.0.2200.5) 
==12924== by 0x36A825680B: g_slice_alloc (in /lib64/libglib-2.0.so.0.2200.5) 
==12924== by 0x36A8257DBD: g_slist_prepend (in /lib64/libglib-2.0.so.0.2200.5) 
==12924== by 0x36A825AB15: g_strsplit (in /lib64/libglib-2.0.so.0.2200.5) 
==12924== by 0x4005C8: main (strsplit.c:10) 
==12924== 
==12924== 252 bytes in 1 blocks are still reachable in loss record 2 of 6 
==12924== at 0x4A04A28: calloc (vg_replace_malloc.c:467) 
==12924== by 0x36A8241707: g_malloc0 (in /lib64/libglib-2.0.so.0.2200.5) 
==12924== by 0x36A8255742: ??? (in /lib64/libglib-2.0.so.0.2200.5) 
==12924== by 0x36A825669D: g_slice_alloc (in /lib64/libglib-2.0.so.0.2200.5) 
==12924== by 0x36A8257DBD: g_slist_prepend (in /lib64/libglib-2.0.so.0.2200.5) 
==12924== by 0x36A825AB15: g_strsplit (in /lib64/libglib-2.0.so.0.2200.5) 
==12924== by 0x4005C8: main (strsplit.c:10) 
==12924== 
==12924== 504 bytes in 1 blocks are still reachable in loss record 3 of 6 
==12924== at 0x4A04A28: calloc (vg_replace_malloc.c:467) 
==12924== by 0x36A8241707: g_malloc0 (in /lib64/libglib-2.0.so.0.2200.5) 
==12924== by 0x36A8255722: ??? (in /lib64/libglib-2.0.so.0.2200.5) 
==12924== by 0x36A825669D: g_slice_alloc (in /lib64/libglib-2.0.so.0.2200.5) 
==12924== by 0x36A8257DBD: g_slist_prepend (in /lib64/libglib-2.0.so.0.2200.5) 
==12924== by 0x36A825AB15: g_strsplit (in /lib64/libglib-2.0.so.0.2200.5) 
==12924== by 0x4005C8: main (strsplit.c:10) 
==12924== 
==12924== 504 bytes in 1 blocks are still reachable in loss record 4 of 6 
==12924== at 0x4A04A28: calloc (vg_replace_malloc.c:467) 
==12924== by 0x36A8241707: g_malloc0 (in /lib64/libglib-2.0.so.0.2200.5) 
==12924== by 0x36A825578B: ??? (in /lib64/libglib-2.0.so.0.2200.5) 
==12924== by 0x36A825669D: g_slice_alloc (in /lib64/libglib-2.0.so.0.2200.5) 
==12924== by 0x36A8257DBD: g_slist_prepend (in /lib64/libglib-2.0.so.0.2200.5) 
==12924== by 0x36A825AB15: g_strsplit (in /lib64/libglib-2.0.so.0.2200.5) 
==12924== by 0x4005C8: main (strsplit.c:10) 
==12924== 
==12924== 720 bytes in 3 blocks are still reachable in loss record 5 of 6 
==12924== at 0x4A04820: memalign (vg_replace_malloc.c:581) 
==12924== by 0x4A048D7: posix_memalign (vg_replace_malloc.c:709) 
==12924== by 0x36A8255F87: ??? (in /lib64/libglib-2.0.so.0.2200.5) 
==12924== by 0x36A8256841: g_slice_alloc (in /lib64/libglib-2.0.so.0.2200.5) 
==12924== by 0x36A8257DBD: g_slist_prepend (in /lib64/libglib-2.0.so.0.2200.5) 
==12924== by 0x36A825AB15: g_strsplit (in /lib64/libglib-2.0.so.0.2200.5) 
==12924== by 0x4005C8: main (strsplit.c:10) 
==12924== 
==12924== 2,032 bytes in 1 blocks are still reachable in loss record 6 of 6 
==12924== at 0x4A04A28: calloc (vg_replace_malloc.c:467) 
==12924== by 0x36A8241707: g_malloc0 (in /lib64/libglib-2.0.so.0.2200.5) 
==12924== by 0x36A8256642: g_slice_alloc (in /lib64/libglib-2.0.so.0.2200.5) 
==12924== by 0x36A8257DBD: g_slist_prepend (in /lib64/libglib-2.0.so.0.2200.5) 
==12924== by 0x36A825AB15: g_strsplit (in /lib64/libglib-2.0.so.0.2200.5) 
==12924== by 0x4005C8: main (strsplit.c:10) 
==12924== 
==12924== LEAK SUMMARY: 
==12924== definitely lost: 0 bytes in 0 blocks 
==12924== indirectly lost: 0 bytes in 0 blocks 
==12924==  possibly lost: 0 bytes in 0 blocks 
==12924== still reachable: 4,252 bytes in 8 blocks 
==12924==   suppressed: 0 bytes in 0 blocks 
==12924== 
==12924== For counts of detected and suppressed errors, rerun with: -v 
==12924== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6)

我的问题是：我没有正确清理或是这些错误的东西，可以安全地忽略？

谢谢！

来源

2012-04-09 Scott Frazer

从valgrind documentation，

因为有各种不同的泄漏与严重程度不同，一个有趣的问题是：漏出应该算作真正 “错误的”，哪些不应该？

绝对丢失和可能丢失的块被视为真正的“错误”。即使已指定--show-reachable = yes并且它们是已打印，但间接丢失且仍可到达的块不计为真 “错误”; 这是因为这样的块不需要程序员直接修复。

因此，您可以放心地忽略这些错误，因为这些块无论如何都会在程序退出时被重新声明。

也阅读了本SO线程里面详细地讨论Valgrind的内存错误

Still Reachable Leak detected by Valgrind

来源

2012-04-09 19:04:30

-1

Program received signal SIGSEGV, Segmentation fault. 

in g_slice_alloc() from /usr/local/lib/libglib-2.0.so.0 

(gdb) backtrace 
in g_slice_alloc() from /usr/local/lib/libglib-2.0.so.0 
in g_slist_prepend() from /usr/local/lib/libglib-2.0.so.0 
in g_strsplit() from /usr/local/lib/libglib-2.0.so.0

猜想，也有一些是在巧舌如簧分配走错了。许多其他使用Glib的项目也存在这样的问题。

来源

2012-07-16 08:49:13 visitor

该评论是没有用的。此外，你可能想尝试重新编译你的本地glib-2.0安装。 – hillu 2012-07-16 12:07:58

This document可能有助于了解Valgrind/memcheck检测到哪种泄漏。

至于问题本身，首先不要在GLib中使用默认的slice-allocator在基于GLib的程序上运行valgrind，因为这会在valgrind日志中给出很多“垃圾”输出。只需运行程序指示GLib使用普通malloc：

$ G_DEBUG=always-malloc valgrind --leak-check=full --show-reachable=yes your-program your-args

来源

2014-07-15 14:34:46 Aleksander

巧舌如簧：Valgrind的报告“仍可达” g_strsplit

回答

相关问题