GNOME Bugzilla – Bug 629058
mime part leak
Last modified: 2013-03-20 11:38:18 UTC
==31478== 12,917 (696 direct, 12,221 indirect) bytes in 3 blocks are definitely lost in loss record 42,743 of 43,070 ==31478== at 0x4A0515D: malloc (vg_replace_malloc.c:195) ==31478== by 0x3D3D645C80: g_malloc (gmem.c:134) ==31478== by 0x3D3D65C796: g_slice_alloc (gslice.c:836) ==31478== by 0x3D3D65CA45: g_slice_alloc0 (gslice.c:848) ==31478== by 0x3D3DE32EA3: g_type_create_instance (gtype.c:1867) ==31478== by 0x3D3DE108DB: g_object_constructor (gobject.c:1482) ==31478== by 0x3D3DE13308: g_object_newv (gobject.c:1347) ==31478== by 0x3D3DE1455B: g_object_new (gobject.c:1178) ==31478== by 0x79DDA24: multipart_construct_from_parser (camel-multipart.c:312) ==31478== by 0x79D1718: camel_mime_part_construct_content_from_parser (camel-mime-part-utils.c:135) ==31478== by 0x79D309D: mime_part_construct_from_parser (camel-mime-part.c:710) ==31478== by 0x79CF003: mime_message_construct_from_parser (camel-mime-message.c:306)
The multipart_construct_from_parser() logic looks fine, my guess is CamelMultipart (or one of its subclasses) is leaking parts.
The log itself, without steps, is less useful, also because the log is cut, doesn't show where the mime part was created. Could you retest with something more recent, like 3.6.x+, and provide steps, please? Thanks in advance. I run evolution (git master, 3.7.92) under valgrind and found other memory leaks, not thins one, but it can only mean that I didn't pass through the code you did.
I'm not sure I ever knew what I actually did to trigger this, even at the time. I just ran Evolution in valgrind and used it 'in anger' for a while, then inspected the log. FWIW I'm still seeing Evolution grow to gigabytes of memory, and need to kill it every few days to recover. There still appear to be massive memory leaks. Probably GObject leaks rather than pure store leaks; I think we got to the point where valgrind wasn't showing much.
(In reply to comment #3) > FWIW I'm still seeing Evolution grow to gigabytes of memory, and need to kill > it every few days to recover. There still appear to be massive memory leaks. True. I addressed few of them in bug #656488 and bug #696173, while there can be more, both fixed and still there. Would you mind, if I close this one? As I said above, I didn't see this particular one in my valgrind log of git master.
Yeah, please go ahead and close any of these leak bugs that I filed in 2010 with just the valgrind complaint. They were mostly just to help me keep track of all the valgrind output, and to give me a real bug number when pushing fixes to the stable branch at the time. I did fix most of them, I think, but the ones which slipped through can be dropped now. It's more interesting just to run valgrind again and look for current issues. Thanks.