GNOME Bugzilla – Bug 563952
huge continiuos memory consumption
Last modified: 2010-02-17 03:46:39 UTC
when using mapi, evolution continuously consume more and more memory using latest svn revision (24). (although this behavior was always present with every revision i have tested) step to reproduce: 1. setup mapi email account. 2. check for new-mails (hit F9) 3. watch for memory usage increase in my case the situation is as follows (top output): evolution: VIRT: 1210m RES: 344m hit f9 evolution: VIRT: 1210m RES: 360m hit f9 evolution: VIRT: 1239m RES: 373m hit f9 evolution: VIRT: 1312m RES: 388m hit f9 evolution: VIRT: 1324m RES: 407m hit f9 evolution: VIRT: 1355m RES: 420m i have played with valgrind. seen many definitive losts. i will be glad to help (provide needed valgrind logs, etc) p.s. i have tried to put several aka g_free statements in the source files that valgrind point. but i am not sure about the effect.
Yep .. I guess memory was kinda ignored during development. Feel free to send in patches.. Would be good to have the valgrind logs here ..
Created attachment 124491 [details] valgrind log i attached valgrind log it is large:) so i will provide some info : 64 byte indirect loss: camel-mapi-store.c around lline 860 --- url = camel_url_new(priv->base_url,NULL); g_free(url->path); url->path = g_strdup_printf("/%s", fi->full_name); fi->uri = camel_url_to_string(url,CAMEL_URL_HIDE_ALL); // suspected! camel_url_free(url); // --- 43480 bytes definitely lost: camel-mapi-store.c around line 988 --- id = g_strdup_printf ("%016llX", exchange_mapi_folder_get_fid (folder)); fi = g_new0 (CamelFolderInfo, 1); // suspected! if (folder->is_default) { --- 29775 bytes definitely lost: exchange-mapi-utils around line 50 --- mem_ctx = talloc_init ("ExchangeMAPI_utf8tolinux"); newstr = windows_to_utf8(mem_ctx, wstring); // suspected! if (g_utf8_validate (newstr, -1, NULL)) --- exchange-mapi-connection.c around lines 2481 - 2488 --- newname = utf8tolinux (name); // suspected! g_print("\n|---+ %-15s : (Container class: %s %016llX) UnRead : %d Total : %d ", newname, class, *fid, unread ? *unread : 0, total ? *total : 0); folder = exchange_mapi_folder_new (newname, class, folder_hier, *fid, folder_id, child ? *child : 0, unread ? *unread : 0, total ? *total : 0); *mapi_folders = g_slist_prepend (*mapi_folders, folder); if (child && *child) result = (result && get_child_folders(mem_ctx, folder_hier, &obj_folder, *fid, mapi_folders)); //suspected! g_free (newname); --- p.s. i have try to use some g_free statements but i dont think they helped:)
There are some leaks in and around GetNamesFromIDs which are valid leaks in Samba. Please don't work-around those :-) We should probably get the Samba guys' attention to that ASAP.
I can confirm this one as well. Really a show stopper for me. Since it uses over 2.3G eventually making my system unusable. If someone could show me how to help out, I will. Because I really want to see this working again. (after the switch of server side software made owa unusable.)
True for my setup as well. VIRT 1023M and rising.. $ apt-cache policy evolution-mapi evolution-mapi: Installed: 0.26.0.1-0ubuntu1 Candidate: 0.26.0.1-0ubuntu1 Version table: *** 0.26.0.1-0ubuntu1 0 500 http://se.archive.ubuntu.com jaunty/universe Packages 100 /var/lib/dpkg/status
Today I have tried again, because other issues were resolved. But still the memory consumption is huge! Right now: virt res shr S %CPU%mem time+ command 2024m 706m 6304 S 140 70.5 11:47.09 evolution Could someone explain how we can help in tracking the bug?
Mem: 3932544k total, 3910216k used, 22328k free, 480k buffers Swap: 4000176k total, 2353512k used, 1646664k free, 30288k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 6886 piasekr 20 0 5840m 3.2g 2356 R 95 85.8 3:06.94 evolution I'm using owa-mapi connector and memory usage is quite surprising. Usually it doesn't use _that_ much - up to 1GB. I'm not using the latest trunk version - but 2.24.5. I'll do some more testing on 2.26.
libmapi 0.9 has many memory leak fixes. It will be great to know the feed back with libmapi 0.9 and evolution-mapi 0.29.x / 0.28.x, thanks.
I can provide positive feedback regarding memory issue. It is possible now to leave evolution running for a long time. No memory "eating" observed. just ran some mem stress test. seems good p.s. using latest svn evolution-mapi
Thanks a lot. Please feel free to open a new bug if you see memory leaks any time later.