GNOME Bugzilla – Bug 363328
Memory Leak in Evo 2.8.0 and 2.8.1
Last modified: 2007-02-23 02:46:27 UTC
I've been noticing a memory leak in Evolution 2.8.0 and also 2.8.1. I have two pop-based e-mail accounts. Everytime a Send/Receive is executed, the Resident memory goes up 4-5MB. With automatic Send/Receive commands being executed every 10 minutes, I can't run Evolution overnight without it taking up half my available memory (768MB). The leak happens whether I manually press the Send/Receive button or if it's done automatically. I ran valgrind with leak checking on. I'll attach the output file.
Created attachment 74995 [details] Valgrind output with leak checking turned on
Thanks for the valgrind output, Nathan - however, will it be possible for you to attach a new one with "--num-callers" set to some high number?
Created attachment 77725 [details] valgrind with --leak-check=full and --num-callers=40 Evolution 2.8 on FC 6, same problem as described by Nathan.
Created attachment 78541 [details] Valgrind with --leak-check=full and --num-callers=100 Another valgrind output. Sorry it took so long. I'm looking at this, and more and more I think it's due to libsoftokn3.so (part of libnss from Mozilla, I think). Although I've tried to install debug libraries for this, I'm just not ready to recompile Firefox (which is where the libnss libraries come from in Mandriva). It's interesting that the same problem has shown up on Fedora Core. I'm using Firefox 1.5.0.8 (problem with 1.5.0.x in general). libnss3 is the same version as Firefox.
Ran into the same memory leak problem on Kubuntu 6.10. I have one POP3 account set up, and resident mem usage of Evolution 2.8.1 is growing 10mb for each send/receive session. I tried to run it in valgrind, but it reliably crashed on exit. My env is stock Kubuntu "Edgy" 6.10, except kernel 2.6.18.2 built from source. Installed packages: evolution 2.8.1-0ubuntu4 evolution-data-server 1.8.1-0ubuntu3 evolution-data-server-common 1.8.1-0ubuntu3 evolution-plugins 2.8.1-0ubuntu4 libnss3 1.firefox2.0+0dfsg-0ubuntu3 libnspr4 1.firefox2.0+0dfsg-0ubuntu3 Other stuff that may be relevant - kernel includes Exec-Shield patch, and I ran prelink on all binaries and libraries in the system.
A little more information: If I enable only my unencrypted POP3 account and then do send/receive, the memory leak occurs. However if I only use my SSL-encrypted POP3 account and then do a send/receive, no memory leak occurs. I don't know what happens with TLS, but it maybe the encryption piece from libnss isn't the problem after all. I don't know anything about the mail component, so I while I can try to track the leak down I doubt I'll get anywhere.
(In reply to comment #6) > A little more information: If I enable only my unencrypted POP3 account and > then do send/receive, the memory leak occurs. However if I only use my > SSL-encrypted POP3 account and then do a send/receive, no memory leak occurs. > > I don't know what happens with TLS, but it maybe the encryption piece from > libnss isn't the problem after all. I don't know anything about the mail > component, so I while I can try to track the leak down I doubt I'll get > anywhere. > I am having the same problem on Ubuntu 6.10 (edgy) and have found that turning OFF the message deletion on the server after x days stops the memory leak. (Edit -> Preferences -> Select your account -> Edit -> Receiving Options -> Delete after x days). Can you try the same to see if it solves the problem for you? If it does, that should give some direction as to where the problem lies.
(In reply to comment #7) I confirm Tam's finding. Turning off deletion of mail messages on the server after x days stopped the memory leak on my machine.
Hi. For me, I had to turn on --still-reachable=yes to see it. I'm losing about 40MB with each send/receive with 1200 messages in the pop mailbox on a dovecot server. I'll rerun it with a larger --num-callers tomorrow. Thanks! -ellie ==13880== ==13880== 277,604,944 bytes in 13,259 blocks are still reachable in loss record 251 of 251 ==13880== at 0x4021492: realloc (vg_replace_malloc.c:306) ==13880== by 0x49EABAA: g_realloc (in /usr/lib/libglib-2.0.so.0.1200.4) ==13880== by 0x4995860: (within /usr/lib/libgobject-2.0.so.0.1200.4) ==13880== by 0x4996188: g_signal_newv (in /usr/lib/libgobject-2.0.so.0.1200.4) ==13880== by 0x49968FB: g_signal_new_valist (in /usr/lib/libgobject-2.0.so.0.1200.4) ==13880== by 0x4420922: _gtk_binding_signal_new (in /usr/lib/libgtk-x11-2.0.so.0.1000.6) ==13880== by 0x44F8951: (within /usr/lib/libgtk-x11-2.0.so.0.1000.6) ==13880== by 0x49A2C70: g_type_class_ref (in /usr/lib/libgobject-2.0.so.0.1200.4) ==13880== by 0x498931A: g_object_newv (in /usr/lib/libgobject-2.0.so.0.1200.4) ==13880== by 0x498973E: g_object_new_valist (in /usr/lib/libgobject-2.0.so.0.1200.4) ==13880== by 0x49898EF: g_object_new (in /usr/lib/libgobject-2.0.so.0.1200.4) ==13880== by 0x44F59F6: gtk_menu_new (in /usr/lib/libgtk-x11-2.0.so.0.1000.6) ==13880== ==13880== LEAK SUMMARY: ==13880== definitely lost: 3,946 bytes in 44 blocks. ==13880== indirectly lost: 120 bytes in 10 blocks. ==13880== possibly lost: 445,588 bytes in 976 blocks. ==13880== still reachable: 304,358,763 bytes in 622,317 blocks. ==13880== suppressed: 0 bytes in 0 blocks.
(In reply to comment #7) > I am having the same problem on Ubuntu 6.10 (edgy) and have found that turning > OFF the message deletion on the server after x days stops the memory leak. > (Edit -> Preferences -> Select your account -> Edit -> Receiving Options -> > Delete after x days). Can you try the same to see if it solves the problem for > you? If it does, that should give some direction as to where the problem lies. That's it! In the connection that I'm having problems with, I delete messages from the server after 91 days. Turning that off stops the memory leak. Great find.
Created attachment 82243 [details] [review] Fix for memory leak Found the problem. In EDS file camel/providers/pop3/camel-pop3-folder.c, function camel_pop3_delete_old() had a memory leak. It's a one-line change. I've added the line: camel_object_unref((CamelObject *)message); The patch has a few more lines changed because I found a few other potential problems. For instance, the "message" variable was being used to calculate message_time before it was being checked to see if it was NULL. This could have caused a crash. I've also reformatted some of the code because it was near impossible to read due to indentation being incorrect (i.e. not consistent with the rest of the file). Please try the patch out and let me know if it works for you all.
Note: patch is against SVN, but should work for 2.8.x as well since the file hasn't changed in 6 months.
Patch looks really neat. Please commit it to both SVN HEAD and stable branch. Thanks for the good work, as usual, Nathan.
Commited to both branches. Thanks.
Nathan: If you want to send your email address to nerdygirl_ellie@ nospam yahoo.com (obviously remove the nospam), I will Paypal you some $! Otherwise, a million thanks! -Ellie
Glad you like it. I do this for fun and to give back to the community - I get paid at work to do things I couldn't otherwise do with open source (i.e. work with customized hardware).