On Tue, Jan 2, 2007, Paul J Stevens <[EMAIL PROTECTED]> said: > Justin McAleer wrote: >> Progress is progress. Let me know if I can help with any debugging. >> >> Aaron Stone wrote: >>> On Tue, Jan 2, 2007, Justin McAleer <[EMAIL PROTECTED]> said: >>> >>> >>>> Has any progress been made on the imapd memory leak? >>> >>> There are some fixes in SVN, so 2.2.2 will be an improvement over 2.2.1, >>> but it does not appear to be a complete fix. We'll have to collect more >>> data and continue narrowing down the referenced but forgotten gmime >>> objects. > > > Those 'fixes' don't address *any* leakage at all. But they do address > the general footprint by reducing memory usage in a couple of places. No > significant leakage can be detected using the current test cases, afaik.
To echo Justin, let's not hold 2.2.2 on resolving all memory issues, so long as we've made some improvements. If the suspicion is that we're forgetting to unref gmime objects, we may need some more detailed tracking infrastructure. I was thinking the other day that it would be nice to be able to dump a long of a single IMAP session, from connect to disconnect, with traces of: o Commands and responses issued during the session. o Database queries made for each command. o Memory allocated by each command. With a global tracking structure and a few functions to wrap it, it should be fairly straightforward to instrument the code. When we move to threads, the functions would just bounce through thread local storage to get the global structure assigned to that thread. Actually, this just really got my wheels turning! I'll try to get some initial code hacked up this week. Is there any one or two IMAP commands in particular that we suspect are leaking a lot? Let's pick low-hanging fruit first, of course. Aaron _______________________________________________ Dbmail-dev mailing list [email protected] http://twister.fastxs.net/mailman/listinfo/dbmail-dev
