c - glib:valgrind 在 g_strsplit 之后报告 'still reachable' block

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 运行这段代码时，我得到了一堆“仍然可以到达”的 block :

==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 ,

Because there are different kinds of leaks with different severities, an interesting question is this: which leaks should be counted as true "errors" and which should not?

Definitely lost and possibly lost blocks are counted as true "errors". Indirectly lost and still reachable blocks are not counted as true "errors", even if --show-reachable=yes is specified and they are printed; this is because such blocks don't need direct fixing by the programmer.

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

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

Still Reachable Leak detected by Valgrind