bug-mailutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug-mailutils] Possible memory leak in last git mailutils


From: Kostik
Subject: [bug-mailutils] Possible memory leak in last git mailutils
Date: Mon, 26 Jul 2010 16:29:05 +0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.24) Gecko/20100228 Thunderbird/2.0.0.24 Mnenhy/0.7.6.0

Hi everyone!

Sergey, I got the last mailutils git checkout and I see that in my
application leaks memory.

I created a test message, run mimetest from mailutils examples and valgrind
shows:

$ /vg-in-place --trace-children=yes --leak-check=full ./mimetest ./testmsg.msg

---
==32039== HEAP SUMMARY:
==32039==     in use at exit: 765 bytes in 28 blocks
==32039==   total heap usage: 298 allocs, 270 frees, 52,737 bytes allocated
==32039==
==32039== 39 bytes in 1 blocks are definitely lost in loss record 24 of 28
==32039==    at 0x4022BB5: calloc (vg_replace_malloc.c:418)
==32039==    by 0x4093B67: mu_mime_get_num_parts (mime.c:271)
==32039==    by 0x408FBE3: mu_message_get_num_parts (message.c:726)
==32039==    by 0x8049624: message_display_parts (mimetest.c:242)
==32039==    by 0x804A011: main (mimetest.c:145)
==32039==
==32039== 59 bytes in 1 blocks are definitely lost in loss record 25 of 28
==32039==    at 0x40238CA: realloc (vg_replace_malloc.c:476)
==32039==    by 0x40A3B03: mu_rfc2047_decode (rfc2047.c:228)
==32039==    by 0x4094965: mu_mimehdr_decode_param (mimehdr.c:477)
==32039==    by 0x4095349: mu_message_aget_decoded_attachment_name
(mimehdr.c:683)
==32039==    by 0x8049A47: message_display_parts (mimetest.c:272)
==32039==    by 0x804A011: main (mimetest.c:145)
==32039==
==32039== 88 bytes in 1 blocks are definitely lost in loss record 26 of 28
==32039==    at 0x4022BB5: calloc (vg_replace_malloc.c:418)
==32039==    by 0x409125B: mu_message_create (message.c:83)
==32039==    by 0x40937EF: _mime_append_part (mime.c:90)
==32039==    by 0x4093E36: mu_mime_get_num_parts (mime.c:339)
==32039==    by 0x408FBE3: mu_message_get_num_parts (message.c:726)
==32039==    by 0x8049FD3: main (mimetest.c:140)
==32039==
==32039== 92 (32 direct, 60 indirect) bytes in 1 blocks are definitely lost
in loss record 27 of 28
==32039==    at 0x4022BB5: calloc (vg_replace_malloc.c:418)
==32039==    by 0x40882A7: mu_list_create (list.c:48)
==32039==    by 0x4072ECE: mu_authority_set_authenticate (auth.c:157)
==32039==    by 0x40730F0: mu_authority_create_null (auth.c:44)
==32039==    by 0x4029CD6: _folder_mbox_init (folder.c:603)
==32039==    by 0x4082690: mu_folder_create_from_record (folder.c:119)
==32039==    by 0x408AD4D: _create_mailbox0 (mailbox.c:66)
==32039==    by 0x408AF01: mu_mailbox_create (mailbox.c:178)
==32039==    by 0x408DEC3: mu_mailbox_create_default (mbx_default.c:448)
==32039==    by 0x8049E79: main (mimetest.c:105)
==32039==
==32039== 99 bytes in 1 blocks are definitely lost in loss record 28 of 28
==32039==    at 0x40237D8: malloc (vg_replace_malloc.c:195)
==32039==    by 0x4089547: lock_dotlock (locker.c:745)
==32039==    by 0x4089AFE: _mu_locker_lock (locker.c:545)
==32039==    by 0x4089B5D: mu_locker_lock (locker.c:567)
==32039==    by 0x402F116: mbox_scan0 (mboxscan.c:453)
==32039==    by 0x402B0FF: mbox_messages_count (mbox.c:1762)
==32039==    by 0x4089F09: mu_mailbox_messages_count (mailbox.c:354)
==32039==    by 0x8049EB8: main (mimetest.c:119)
==32039==
==32039== LEAK SUMMARY:
==32039==    definitely lost: 317 bytes in 5 blocks
==32039==    indirectly lost: 60 bytes in 3 blocks
==32039==      possibly lost: 0 bytes in 0 blocks
==32039==    still reachable: 388 bytes in 20 blocks
==32039==         suppressed: 0 bytes in 0 blocks
---

In my application valgrind shows two leaks from above listed:
---
==31314== 77 bytes in 1 blocks are definitely lost in loss record 13 of 14
==31314==    at 0x40238CA: realloc (vg_replace_malloc.c:476)
==31314==    by 0x805EF20: mu_rfc2047_decode (rfc2047.c:228)
==31314==    by 0x8057241: mu_mimehdr_decode_param (mimehdr.c:477)
==31314==    by 0x8057A8C: mu_message_aget_decoded_attachment_name
(mimehdr.c:683)
==31314==    by 0x804B138: message_display_files (in findattach)
==31314==    by 0x804AA84: findattach (in findattach)
==31314==    by 0x804A65C: request_FILE (in findattach)
==31314==    by 0x4064368: start_thread (in /lib/libpthread-2.7.so)
==31314==    by 0x414ACFD: clone (in /lib/libc-2.7.so)
==31314==
==31314== 88 bytes in 1 blocks are definitely lost in loss record 14 of 14
==31314==    at 0x4022BB5: calloc (vg_replace_malloc.c:418)
==31314==    by 0x8054D7B: mu_message_create (message.c:83)
==31314==    by 0x805617F: _mime_append_part (mime.c:90)
==31314==    by 0x8056732: mu_mime_get_num_parts (mime.c:339)
==31314==    by 0x804AD75: message_display_files (in findattach)
==31314==    by 0x804AA84: findattach (in findattach)
==31314==    by 0x804A65C: request_FILE (in findattach)
==31314==    by 0x4064368: start_thread (in /lib/libpthread-2.7.so)
==31314==    by 0x414ACFD: clone (in /lib/libc-2.7.so)
---


Sergey, please help with it.


=kostik



reply via email to

[Prev in Thread] Current Thread [Next in Thread]