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 [EMAIL PROTECTED] /home/seb/tmp> gcc `pkg-config --cflags --libs glib-2.0`
main-loop-leak.c -o main-loop-leak
0 [EMAIL PROTECTED] /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 [EMAIL PROTECTED] /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
_______________________________________________
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
