Ah, sorry, forgot to mention that it requires an autoreconf. On Tue, May 15, 2007, Jorge Bastos <[EMAIL PROTECTED]> said:
> Aaron, > Trying to compile last svn to check this mem issue: > > serverparent.c: In function 'serverparent_getopt': > serverparent.c:98: error: 'DBMAIL_VERSION' undeclared (first use in this > function) > serverparent.c:98: error: (Each undeclared identifier is reported only once > serverparent.c:98: error: for each function it appears in.) > make[2]: *** [libdbmail_la-serverparent.lo] Error 1 > make[2]: Leaving directory > `/usr/local/src/postfix/dbmail_svn/dbmail_2_2_branch' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory > `/usr/local/src/postfix/dbmail_svn/dbmail_2_2_branch' > make: *** [all] Error 2 > > > > > ----- Original Message ----- > From: "Aaron Stone" <[EMAIL PROTECTED]> > To: "DBMail mailinglist" <[email protected]> > Sent: Tuesday, May 15, 2007 10:13 PM > Subject: Re: [Dbmail] dbmail-imapd memory leak > > >> Looks like we were not correctly freeing the lists returned by >> g_list_slices. I've updated dbmail-imapsession.c, dbmail-mailbox.c, and >> db.c with a fix. Hopefully imapsync users will feel less pain. Please >> test out SVN and let me know! >> >> Aaron >> >> On Mon, 2007-05-14 at 23:29 -0400, Leif Jackson wrote: >>> Humm looks like it might be in the ic_fetch: >>> >>> ==26918== 37,800 bytes in 54 blocks are still reachable in loss record >>> 23 of 27 >>> ==26918== at 0x40235AB: realloc (vg_replace_malloc.c:306) >>> ==26918== by 0x428CF4A: vasprintf (in /lib/i686/cmov/libc-2.5.so) >>> ==26918== by 0x41708C6: g_vasprintf (in >>> /usr/lib/libglib-2.0.so.0.1200.12) >>> ==26918== by 0x41629E5: g_strdup_vprintf (in >>> /usr/lib/libglib-2.0.so.0.1200.12) >>> ==26918== by 0x41D73AE: g_list_append_printf (in >>> /usr/lib/dbmail/libdbmail.so.0.0.0) >>> ==26918== by 0x41C57B7: g_list_slices (in >>> /usr/lib/dbmail/libdbmail.so.0.0.0) >>> ==26918== by 0x8052534: dbmail_imap_session_mailbox_update_recent (in >>> /usr/sbin/dbmail-imapd) >>> ==26918== by 0x8055D74: dbmail_imap_session_fetch_get_items (in >>> /usr/sbin/dbmail-imapd) >>> ==26918== by 0x804E707: _ic_fetch (in /usr/sbin/dbmail-imapd) >>> ==26918== by 0x804EBCA: _ic_uid (in /usr/sbin/dbmail-imapd) >>> ==26918== by 0x804CD50: IMAPClientHandler (in /usr/sbin/dbmail-imapd) >>> ==26918== by 0x41DD7F2: PerformChildTask (in >>> /usr/lib/dbmail/libdbmail.so.0.0.0) >>> >>> but I don't have enough time untill maybe this weekend to dig into it >>> maybe Aaron or Paul have a sec to look into it (In my other debuging I >>> noticed a lot of the valgrind complaints for g_list_append_printf, but >>> if there is a memleak there it must be in glib? humm...). But since your >>> script does a lot of fetches with large arguments I suspect it is >>> somewhere in there. Thanks for the debug info! >>> >>> -Leif >>> >>> > Here it is: http://rabbit.us/pool/misc/dbmail_bug584_memcheck.tar.bz2 >>> > The tar contains the same information as the previous one. None of the >>> > options I used before work - I guess they are specific to massif. >>> > Let me know what to do next. >>> > >>> > Peter >>> > _______________________________________________ >>> > DBmail mailing list >>> > [email protected] >>> > https://mailman.fastxs.nl/mailman/listinfo/dbmail >>> > >>> >>> _______________________________________________ >>> DBmail mailing list >>> [email protected] >>> https://mailman.fastxs.nl/mailman/listinfo/dbmail >> >> _______________________________________________ >> DBmail mailing list >> [email protected] >> https://mailman.fastxs.nl/mailman/listinfo/dbmail >> > > _______________________________________________ > DBmail mailing list > [email protected] > https://mailman.fastxs.nl/mailman/listinfo/dbmail > -- _______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
