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
