Question

我有一段非常简单的代码：

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

int main(int argc, char * argv[])
{
  const char * path = "/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)

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

谢谢！

Answer 1

来自valgrind documentation，

因为有不同类型的泄漏具有不同的严重程度，   一个有趣的问题是：哪些泄漏应该算作真实   “错误”，哪些不应该？

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

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

另请阅读此SO线程详细讨论了Valgrind内存错误

Still Reachable Leak detected by Valgrind

Answer 2

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

至于问题本身，首先不要使用GLib中的默认slice-allocator在基于GLib的程序上运行valgrind，因为这会在valgrind日志中为你提供大量的'garbage'输出。只需运行程序指示GLib使用普通mallocs：

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

Answer 3

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中的分配出了问题。许多其他使用Glib的项目也存在这样的问题。

glib：valgrind在g_strsplit之后报告“仍然可到达”的块

3 个答案: