how do I plug this glib main loop memory leak?

[Sebastian Kuzminsky <seb highlab com>]

I'm not understanding something about the glib main loop and reference
counting.

I've got this trivial program that does nothing:


----- begin -----

    #include <signal.h>
    #include <stdio.h>
    #include <glib.h>

    GMainLoop* main_loop = NULL;


    void signal_handler(int signo) {
        printf("caught signal %d\n", signo);
        g_main_loop_quit(main_loop);
    }


    int main(int argc, char *argv[]) {
        main_loop = g_main_loop_new(NULL, TRUE);

        signal(SIGTERM, signal_handler);
        signal(SIGINT, signal_handler);

        while (g_main_loop_is_running(main_loop)) {
            printf("top of main loop\n");
            g_main_context_iteration(NULL, TRUE);
        }

        printf("cleaning up and exiting\n");

        g_main_loop_unref(main_loop);

        return 0;
    }

----- end -----


It looks a little funny because it's reduced from a bigger program.
I run this under valgrind and hit ^C:

0 seb dub /home/seb/tmp>  gcc `pkg-config --cflags --libs glib-2.0` main-loop-leak.c -o main-loop-leak
0 seb dub /home/seb/tmp>  valgrind --show-reachable=yes --leak-check=yes ./main-loop-leak
==3880== Memcheck, a memory error detector.
==3880== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==3880== Using LibVEX rev 1606, a library for dynamic binary translation.
==3880== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==3880== Using valgrind-3.2.0-Debian, a dynamic binary instrumentation framework.
==3880== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==3880== For more details, rerun with: -v
==3880==
--3880-- DWARF2 CFI reader: unhandled CFI instruction 0:50
--3880-- DWARF2 CFI reader: unhandled CFI instruction 0:50
top of main loop
caught signal 2
cleaning up and exiting
==3880==
==3880== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 13 from 1)
==3880== malloc/free: in use at exit: 5,196 bytes in 14 blocks.
==3880== malloc/free: 15 allocs, 1 frees, 5,208 bytes allocated.
==3880== For counts of detected errors, rerun with: -v
==3880== searching for pointers to 14 not-freed blocks.
==3880== checked 69,340 bytes.
==3880==
==3880== 1,472 bytes in 8 blocks are still reachable in loss record 1 of 2
==3880==    at 0x401DBE6: memalign (vg_replace_malloc.c:332)
==3880==    by 0x401DC75: posix_memalign (vg_replace_malloc.c:386)
==3880==    by 0x406F287: (within /usr/lib/libglib-2.0.so.0.1000.3)
==3880==    by 0x406FC9A: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.1000.3)
==3880==    by 0x404102A: g_ptr_array_sized_new (in /usr/lib/libglib-2.0.so.0.1000.3)
==3880==    by 0x4041071: g_ptr_array_new (in /usr/lib/libglib-2.0.so.0.1000.3)
==3880==    by 0x40598F6: g_main_context_new (in /usr/lib/libglib-2.0.so.0.1000.3)
==3880==    by 0x4059AB8: g_main_context_default (in /usr/lib/libglib-2.0.so.0.1000.3)
==3880==    by 0x405A2E4: g_main_loop_new (in /usr/lib/libglib-2.0.so.0.1000.3)
==3880==    by 0x804856B: main (in /home/seb/slask/snippits/c/glib2.0/main-loop-leak)
==3880==
==3880==
==3880== 3,724 bytes in 6 blocks are still reachable in loss record 2 of 2
==3880==    at 0x401DA06: calloc (vg_replace_malloc.c:279)
==3880==    by 0x406051D: g_malloc0 (in /usr/lib/libglib-2.0.so.0.1000.3)
==3880==    by 0x405989F: g_main_context_new (in /usr/lib/libglib-2.0.so.0.1000.3)
==3880==    by 0x4059AB8: g_main_context_default (in /usr/lib/libglib-2.0.so.0.1000.3)
==3880==    by 0x405A2E4: g_main_loop_new (in /usr/lib/libglib-2.0.so.0.1000.3)
==3880==    by 0x804856B: main (in /home/seb/slask/snippits/c/glib2.0/main-loop-leak)
==3880==
==3880== LEAK SUMMARY:
==3880==    definitely lost: 0 bytes in 0 blocks.
==3880==      possibly lost: 0 bytes in 0 blocks.
==3880==    still reachable: 5,196 bytes in 14 blocks.
==3880==         suppressed: 0 bytes in 0 blocks.
0 seb dub /home/seb/tmp>


The way I read this, g_main_loop_new() is allocating memory and not
freeing it, even though I quit the loop and unref it.  Clue in a helpless
noob, what's going on here?


This is with 2.10.3, by the way, on a Debian Etch/Sid system.


-- 
Sebastian Kuzminsky      FUSION OF BRUNDLEFLY AND TELEPORTER POD SUCCESSFUL