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 _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list