On 02/22/2006 03:02:27 AM, Timo Sirainen wrote:
Yes, this isn't unexpected since I'm also seeing the heap grow
slowly. But since it's grown only 1.5MB in 30 hours (to 3MB), that
isn't too bad of a problem.Could you try running imap with some memory leak detection tool/ library, such as Valgrind or dmalloc? I know I should try that myself
also..
Even though from another mail in this thread I learned that you found some leak(s) already, today I had the time to run valgrind on Dovecot imap.
It made dovecot pretty slow, and my mail client (balsa) didn't like it much (mostly disconnecting for timeout). In fact, at one point it crashed because it had received a block of garbage data - this was the trace leading up to it:
IMAP mailbox: imap://wriede@athena.riede.org/Root
IMAP C: DONE
IMAP C: b2 NOOP
IMAP S: 0 OK Idle completed.
IMAP S: b2 OK NOOP completed.
IMAP mailbox: imap://wriede@athena.riede.org/RNW
IMAP C: b3 NOOP
IMAP S:
I can't tell whether the sending or the receiving end is to blame, but given that server and client are on the same PC, it is not likely to be a transmission error. But I digress.
I opened a bunch of mailboxes, read some mail, did a couple of searches.
Valgrind found many leaked blocks in each invocation of imap. The typical range of leaked memory is from several hundred bytes to 100K, but one process stood out:
==4353== definitely lost: 18,463,192 bytes in 18,029 blocks.
I'm sending the log files seperately to Timo, as loading everybody's inbox with that is not appropriate.
Regards, Willem Riede.