Hi, * Kyle Wheeler [06-07-08 04:25:32 -0400] wrote: I can't really judge on the first one.
784 (16 direct, 768 indirect) bytes in 1 blocks are definitely lost in
loss record 217 of 279
at 0x401B422: malloc (vg_replace_malloc.c:149)
by 0x80C2020: safe_malloc (lib.c:146)
by 0x80C6433: mutt_buffer_init (muttlib.c:1388)
by 0x80EABF3: imap_new_idata (util.c:264)
by 0x80E33C3: imap_conn_find (imap.c:350)
by 0x80E3A54: imap_open_mailbox (imap.c:553)
by 0x80928BC: mx_open_mailbox (mx.c:698)
by 0x8087389: main (main.c:963)
That looks like the 2nd one from one of my older runs: <http://user.cs.tu-berlin.de/~pdmef/tmp/valgrind.txt>On first sight, you're fix really leaks memory since the IMAP_DATA::cmdbuf member is a BUFFER*, not char*. So at least you should use mutt_buffer_free() on it, not FREE().
Btw, I wonder what '16 direct, 768 indirect' means. A wild guess is that 16 count for the BUFFER* itself (8 for long long=size_t, 4 for working pointer, 4 for data pointer) and the rest for BUFFER::data inside or "indirect".
However, I think we can ignore this one. Your patch adds the FREE() call to imap_logout() which is only used in imap_logout_all() which is only used in main.c right before exiting. The OS will mark any memory of the process as available after its exit regardless of whether it was leaked or not, so...
I think it's a good practice to, when mutt is compiled as a debug version, totally clean up all of its memory so real leaks can be more easily identified.
bye, Rocco -- :wq!