glib: valgrind reporting 'still reachable' blocks after g_strsplit

Question

I have a very simple piece of code:

#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;
}

However, when I run this code through Valgrind, I get a bunch of 'still reachable' blocks:

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

My question is: did I not clean up properly or are these errors something that can be safely ignored?

Thanks!

score 1 · Accepted Answer · edited May 23 '17 at 12:20

From 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.

So you can safely ignore these errors as these blocks will be anyways re-claimed at program exit.

Also read this SO thread which discussed Valgrind memory errors in detail

Still Reachable Leak detected by Valgrind

score 1 · Answer 2 · edited Jul 15 '14 at 14:52

This document may help to understand which kind of leaks Valgrind/memcheck detects.

As for the issue itself, first don't run valgrind on a GLib-based program using the default slice-allocator in GLib, as that will give you lots of 'garbage' output in the valgrind log. Just run the program instructing GLib to use plain mallocs:

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

score -1 · Answer 3 · edited Jul 16 '12 at 11:41

-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

Guess, there is something going wrong with the allocation in glib. Many other projects which use Glib also have such issues.

edited Jul 16 '12 at 11:41

Taryn

242,637
56
362
405

answered Jul 16 '12 at 08:49

visitor

1

1

The comment is not helpful. Also, you may want to try recompiling your local glib-2.0 installation. – hillu Jul 16 '12 at 12:07

glib: valgrind reporting 'still reachable' blocks after g_strsplit

3 Answers3