使用Valgrind调查的Glib内存泄漏

Question

I know that there is similiar thread before here about this problem and on this site https://live.gnome.org/Valgrind had been explained, I wrote my simple program below

  #include <glib.h>
  #include <glib/gprintf.h>
  #include <iostream>

  int main()
 {
const gchar *signalfound = g_strsignal(1);
std::cout <<  signalfound<< std::endl;
return 0; 
  }

but when I tried to check using valgrind using this command G_DEBUG=gc-friendly G_SLICE=always-malloc valgrind --leak-check=full --leak-resolution=high ./g_strsignal

and here is the result

   ==30274== Memcheck, a memory error detector
   ==30274== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
   ==30274== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
   ==30274== Command: ./g_strsignal
   ==30274== Parent PID: 5201
   ==30274== 
   ==30274== 
   ==30274== HEAP SUMMARY:
   ==30274==     in use at exit: 14,746 bytes in 18 blocks
   ==30274==   total heap usage: 24 allocs, 6 frees, 23,503 bytes allocated
   ==30274== 
   ==30274== LEAK SUMMARY:
   ==30274==    definitely lost: 0 bytes in 0 blocks
   ==30274==    indirectly lost: 0 bytes in 0 blocks
   ==30274==      possibly lost: 0 bytes in 0 blocks
   ==30274==    still reachable: 14,746 bytes in 18 blocks
   ==30274==         suppressed: 0 bytes in 0 blocks
   ==30274== Reachable blocks (those to which a pointer was found) are not shown.
   ==30274== To see them, rerun with: --leak-check=full --show-reachable=yes
   ==30274== 
   ==30274== For counts of detected and suppressed errors, rerun with: -v
   ==30274== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

I noticed that what was valgrind said "Reachable blocks (those to which a pointer was found) are not shown.". then I try to check the gmem.c source on corresponding function since I used glib-2.35.4 version. I found following code

   gpointer
   g_malloc (gsize n_bytes)
   {
      if (G_LIKELY (n_bytes))
         {
              gpointer mem;

               mem = glib_mem_vtable.malloc (n_bytes);
               TRACE (GLIB_MEM_ALLOC((void*) mem, (unsigned int) n_bytes, 0, 0));
               if (mem)
              return mem;

               g_error ("%s: failed to allocate %"G_GSIZE_FORMAT" bytes",
                G_STRLOC, n_bytes);
           }

       TRACE(GLIB_MEM_ALLOC((void*) NULL, (int) n_bytes, 0, 0));

   return NULL;
  }

And my question is

1. Is this still a normal situation on where valgrind had said "Reachable blocks (those to which a pointer was found) are not shown.", and I think this statement is refer to the g_malloc function above in which has returning mem a gpointer variable?

2. If not are there any alternatives to solve, "still reachable: 14,746 bytes in 18 blocks" on what valgrind had said above?

I'm running x86 fedora 18 thanks

Answer 1

It most likely refers to dynamically allocated memory returned by the function g_strsignal() .
valgrind says "Reachable blocks...." , because a valid pointer( signalfound ) still points to the dynamically allocated memory.
If Valgrind finds that a pointer to pointing to dynamic memory is lost( overwritten ) then it reports a "definite leak..." , Since it can conclusively say that the dynamic block of memory can never be freed. In your case the pointer still points to the block valgrind does not assume it is lost but it assumes it is probably by design.