On Mon, 2007-04-09 at 01:52 +0000, Aaron Stone wrote: > On Sun, Apr 8, 2007, Paul J Stevens <[EMAIL PROTECTED]> said: > > > Aaron Stone wrote: > >> On Sat, 2007-04-07 at 22:49 +0200, Paul J Stevens wrote: > >>> [EMAIL PROTECTED] wrote: > >>>> This is good evidence that there may be a problem, but doesn't help > >>>> anybody > >>>> to find it. If you can construct a few session transcripts that reliably > >>>> cause memory leaks, we can start tracking it down. > >>> I'm thinking of fixing the code so it will work with libgc. I remember > >>> that was a very instructive exercise that helped the 2.0 code > >>> significantly. I'm not sure though glib and gmime are gc-safe. > >> > >> So long as all memory allocation runs through Glib, we can use this: > >> > >> http://developer.gnome.org/doc/API/2.0/glib/glib-Memory-Allocation.html#GMemVTable > > > > Isn't that used already? And then, how would that help in fixing any > > possible leakage in third party libs we're using (ldap, sql, gmime)? > > We have a lot of dm_malloc, and lots and lots of dm_free. Take a look in > debug.h, where you'll find that they map onto the system's malloc and > free. Worst of all, I think we're mixing g_new with dm_free in some > places.
Huge commit to replace all dm_mallocs, dm_free's with g_malloc, g_new0. Next step is to use g_mem_set_vtable to use a garbage collection engine instead of the usual Glib slices allocation engine. Aaron _______________________________________________ Dbmail-dev mailing list [email protected] http://twister.fastxs.net/mailman/listinfo/dbmail-dev
