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
