Dan Kegel wrote: > Erik de Castro Lopo <mle+...@mega-nerd.com> wrote: > > ==12528== 27,300 bytes in 175 blocks are still reachable in loss record > > 11,194 of 11,196 > > ==12528== at 0x4024C1C: malloc (vg_replace_malloc.c:195) > > ==12528== by 0x4B342E3: g_malloc (gmem.c:131) > > ==12528== by 0x4B4A418: g_slice_alloc (gslice.c:824) > > ==12528== by 0x4B4A714: g_slice_alloc0 (gslice.c:833) > > ==12528== by 0x474F8F6: g_type_create_instance (gtype.c:1654) > > ==12528== by 0x4734747: g_object_constructor (gobject.c:1383) > > ==12528== by 0x4735707: g_object_newv (gobject.c:1171) > > ==12528== by 0x4736589: g_object_new_valist (gobject.c:1323) > > ==12528== by 0x473670D: g_object_new (gobject.c:1086) > > Say no more! We see that tons in chromium's valgrind runs, too.
Well I consider this a *real* leak that needs to be fixed. The code I'm working on has multiple top level windows and the code path in the stack trace gets called for each window; thats 27300 bytes in 175 blocks for every window. In the normal usage of this app, its usual to have more than one window open at any time and to open and close more windows on-the-fly. Under these conditions, my app leaks memory due GTK+ and it seems there is nothing I can do in my code to prevent it. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
