Valgrind and glib

[Ricardo Biloti <biloti ime unicamp br>]

Hi

There is a simple gslist test program which yields a non clean report
when valgrind is employed. The "problem" seems to be in glib. Below I
quote the program and the valgrind output:

-----------------------------

#include <stdlib.h>
#include <glib.h>

GSList *art_alloc_raycode(int *layers, int *waveseq, size_t length)
{
   GSList *raycode;
   size_t j;

   raycode = NULL;

   for(j=0; j<length; j++)
      {
         int *v = (int *) malloc(sizeof(int) * 2);
        
         v[0] = layers[j];
         v[1] = waveseq[j];
        
         raycode = g_slist_append(raycode, v);
      }

   return raycode;
}

void art_free_raycode(GSList *raycode)
{
   GSList *aux;
   if ((aux = raycode) != NULL){

      do{
         free((int *) (aux->data) );
      }while ((aux = aux->next) != NULL);

      g_slist_free(raycode);
   }
}

int main(void)
{
   int rc[2][2] = {{0,0}, {0,0}};
   GSList *raycode;

   raycode = art_alloc_raycode(rc[0], rc[1], 2);

   art_free_raycode(raycode);

   return 0;
}

-----------------------------

gcc sample.c -g -W -Wall `pkg-config --cflags --libs glib-2.0` -o sample

-----------------------------

#  valgrind --show-reachable=yes --leak-check=full ./sample

==6578== Memcheck, a memory error detector for x86-linux.
==6578== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==6578== Using valgrind-2.4.0, a program supervision framework for x86-linux.
==6578== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==6578== For more details, rerun with: -v
==6578==
==6578==
==6578== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 15 from 1)
==6578== malloc/free: in use at exit: 1126 bytes in 4 blocks.
==6578== malloc/free: 6 allocs, 2 frees, 1142 bytes allocated.
==6578== For counts of detected errors, rerun with: -v
==6578== searching for pointers to 4 not-freed blocks.
==6578== checked 83044 bytes.
==6578==
==6578== 20 bytes in 1 blocks are still reachable in loss record 1 of 2
==6578==    at 0x1B906F75: calloc (vg_replace_malloc.c:175)
==6578==    by 0x1B94C96E: g_malloc0 (in /usr/lib/libglib-2.0.so.0.600.4)
==6578==    by 0x1B94E27C: g_allocator_new (in /usr/lib/libglib-2.0.so.0.600.4)
==6578==    by 0x1B95C638: (within /usr/lib/libglib-2.0.so.0.600.4)
==6578==    by 0x1B95BC23: g_slist_append (in /usr/lib/libglib-2.0.so.0.600.4)
==6578==    by 0x804852E: art_alloc_raycode (sample.c:23)
==6578==    by 0x80485CA: main (sample.c:76)
==6578==
==6578==
==6578== 1106 bytes in 3 blocks are still reachable in loss record 2 of 2
==6578==    at 0x1B90659D: malloc (vg_replace_malloc.c:130)
==6578==    by 0x1B94C8E6: g_malloc (in /usr/lib/libglib-2.0.so.0.600.4)
==6578==    by 0x1B95C8C8: g_strdup (in /usr/lib/libglib-2.0.so.0.600.4)
==6578==    by 0x1B94E286: g_allocator_new (in /usr/lib/libglib-2.0.so.0.600.4)
==6578==    by 0x1B95C638: (within /usr/lib/libglib-2.0.so.0.600.4)
==6578==    by 0x1B95BC23: g_slist_append (in /usr/lib/libglib-2.0.so.0.600.4)
==6578==    by 0x804852E: art_alloc_raycode (sample.c:23)
==6578==    by 0x80485CA: main (sample.c:76)
==6578==
==6578== LEAK SUMMARY:
==6578==    definitely lost: 0 bytes in 0 blocks.
==6578==      possibly lost: 0 bytes in 0 blocks.
==6578==    still reachable: 1126 bytes in 4 blocks.
==6578==         suppressed: 0 bytes in 0 blocks.

-----------------------------


Could this be something "dangerous"?

Regards,
--
Ricardo Biloti
Department of Applied Mathematics
IMECC/UNICAMP