Aaron Stone wrote: > 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. >
Silly :-) In debug.h dm_malloc, dm_free etc were already mapped to g_malloc, etc. But still, cleanups like that are never redundant of course. Just for the records though: There was *no* mixing of system malloc and glib malloc. > Next step is to use g_mem_set_vtable to use a garbage collection engine > instead of the usual Glib slices allocation engine. -- ________________________________________________________________ Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands________________________________http://www.nfg.nl _______________________________________________ Dbmail-dev mailing list [email protected] http://twister.fastxs.net/mailman/listinfo/dbmail-dev
