GNOME Bugzilla – Bug 545505
Properly free unused message infos periodically
Last modified: 2011-04-20 12:24:15 UTC
I was just hanging in the browser and this was running on the background. I have some exchange, imap, maildir and pop3 accounts enabled. Distribution: Fedora release 9 (Sulphur) Gnome Release: 2.22.2 2008-05-28 (Red Hat, Inc) BugBuddy Version: 2.22.0 System: Linux 2.6.25.6-55.fc9.x86_64 #1 SMP Tue Jun 10 16:05:21 EDT 2008 x86_64 X Vendor: The X.Org Foundation X Vendor Release: 10499902 Selinux: Permissive Accessibility: Disabled GTK+ Theme: Nodoka Icon Theme: Neu Memory status: size: 704634880 vsize: 704634880 resident: 146731008 share: 21798912 rss: 146731008 rss_rlim: 18446744073709551615 CPU usage: start_time: 1217421340 rtime: 1768 utime: 1342 stime: 426 cutime:0 cstime: 0 timeout: 0 it_real_value: 0 frequency: 100 Backtrace was generated from '/build/local/bin/evolution' [?1034h[Thread debugging using libthread_db enabled] [New Thread 0x7fbad9a7b7f0 (LWP 13577)] [New Thread 0x44c1e950 (LWP 13597)] [New Thread 0x437db950 (LWP 13596)] [New Thread 0x441dc950 (LWP 13595)] 0x00000039a8c0e86f in __libc_waitpid (pid=<value optimized out>, stat_loc=<value optimized out>, options=<value optimized out>) at ../sysdeps/unix/sysv/linux/waitpid.c:41 41 int result = INLINE_SYSCALL (wait4, 4, pid, stat_loc, options, NULL);
+ Trace 204175
----------- .xsession-errors (2336 sec old) --------------------- <memory>:1: Invalid color constant '(null)' Gtk-Message: (for origin information, set GTK_DEBUG): failed to retrieve property `GtkHTML::spell-error-color' of type `GdkColor' from rc file value ""(null)"" of type `gchararray' <memory>:1: Invalid color constant '(null)' Gtk-Message: (for origin information, set GTK_DEBUG): failed to retrieve property `GtkHTML::spell-error-color' of type `GdkColor' from rc file value ""(null)"" of type `gchararray' (SciTE:23102): GLib-GObject-WARNING **: IA__g_object_new_valist: object class `GThemedIcon' has no property named `names' (SciTE:23102): GLib-GIO-CRITICAL **: g_themed_icon_constructed: assertion `themed->names != NULL && themed->names[0] != NULL' failed (SciTE:23102): GLib-CRITICAL **: g_strv_length: assertion `str_array != NULL' failed Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x400001e (Archive Ma) Window manager warning: meta_window_activate called by a pager with a 0 timestamp; the pager needs to be fixed. Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x4a00003 (Evince Doc) Window manager warning: meta_window_activate called by a pager with a 0 timestamp; the pager needs to be fixed. Window manager warning: Invalid WM_TRANSIENT_FOR window 0x4001201 specified for 0x4002395 (Delete acc). --------------------------------------------------
I pick session from summary. SOmething on the way seems to be NULL. CamelSession *session = ((CamelService *)((CamelFolder *)s->folder)->parent_store)->session; Next time, you see it, can you print all values ?
Anytime you got it recently ?
Yes, I got it last week, but the bugboddy doesn't allow me to print the values you requested, thus I run now with a patched version, which prints these values, even no luck in crashing again.
*** Bug 546388 has been marked as a duplicate of this bug. ***
Thx Plaes. Fixed it in trunk.
This doesn't seem to be fixed, as I just got a bug report about the same in 2.28. https://bugzilla.redhat.com/show_bug.cgi?id=541763 Thus I'm reopening it.
Hi, This bug is related to a crash. Its severity must be CRITICAL. Cheers!
bug 604646 looks duplicate
*** Bug 604646 has been marked as a duplicate of this bug. ***
Downstream bug report about the same in 2.28.0: https://bugzilla.redhat.com/show_bug.cgi?id=545853
I got a similar crash in 2.28.2 while changing signature from html to plain text.
Evolution crashed again with similar traces after adding a new search folder and it was looking to fetch correspondent mails.
I didn't see this myself for quite a long time, the last time I was notified on this by Chen was with some issue in IMAPX provider with UID handling, which got sorted out. With that we had some thoughts about this, which I already forgot, unfortunately, but I think they were correct. Thus I'm confirming the bug for further investigation. (I think the clear on timeout doesn't work for some cases, some folders didn't have the timeouter invoked at all and similar - these all and other basic usages need a code review on this). Would be nice to have this sorted out during 2.31 development cycle.
Created attachment 158746 [details] [review] proposed eds patch for evolution-data-server; I'm changing here the camel-folder-summary API functions a bit, together with other fixes making the "free CamelMessageInfo when unused" actually work: a) I removed redundant function camel_folder_summary_reload_from_db and camel_folder_summary_ensure_infos_loaded and replaced them with one camel_folder_summary_prepare_fetch_all. It's better, because no such magic numbers and code to test whether reload from DB or not on various places b) I removed also camel_folder_summary_cache_size, it's not needed anymore c) whenever is loaded a message info from DB, then the release timer is set (it wasn't set before). Also the live time is moved on a load, to ensure just added message info will not be removed in the next second. d) I changed CamelFolderSummary locks to recursive locks, it's better to not release a 'summary_lock' in the middle of message info reading from DB. e) Then I added on couple places call of camel_folder_summary_prepare_fetch_all f) and fixed some refcount issues on CamelMessageInfo-s I noticed while testing this g) together with NNTP fix to unset CAMEL_MESSAGE_FOLDER_FLAGGED on its infos before storing to the summary, because it was never freed from a memory because of this flag.
Created attachment 158747 [details] [review] proposed evo patch for evolution; Applying API changes from the eds.patch, and more refcount "leaks" on CamelMessageInfo, together with using proper function for info free, as documented on camel (note the result is quite the same, but we should be consistent, shouldn't we?).
Created attachment 158748 [details] [review] proposed eex patch for evolution-exchange; Just an API change from eds.patch.
My tests showed it's working as expected, aka loaded infos which are not used more than (up to 2*) SUMMARY_CACHE_DROP seconds are dropped from memory and reloaded on demand. I would appreciate any testing from anyone, as I didn't notice any crash like above, but my use case is too simple for a real testing. There is one little issue with the Templates plugin, as it reloads message infos for Templates folder whenever one selects a message (on actions update). There can be done some re-think for the plugin, but possibly not necessary, as the release time is set for 5 minutes at the moment. I'm only mentioning it here, as I noticed it while testing.
Created attachment 158872 [details] [review] proposed eds patch ][ for evolution-data-server; Updated previous patch to be applicable after yesterday's changes in camel.
*** Bug 616513 has been marked as a duplicate of this bug. ***
There are a couple of things, it would be good not to expose camel_folder_summary_prepare_fetch_all and handle stuffs internally. If its not possible and is really required, it would be good to document the cases in which it should be used. double_ref variable is unused at the moment with the change if I understand correctly, - data.double_ref = TRUE; + data.double_ref = FALSE; if its unused, better to remove it from code. A welcome change to convert the mutexes to recurrent one. Nice fix on using folder_message_info_free at relevant places, would definetly fix some hidden bugs. Please make these changes and commit the patch. Am yet to test the patch. will get the master code running and test it out once its committed. Have been working with stable branch due to downstream work.
Created commit b0b52e4 in eds master (2.31.1+) Created commit ad1b375 in evo master (2.31.1+) Created commit 454c75f in eex master (2.31.1+) I also removed the camel_folder_sync call in the remove_cache function, as we spoke about it on IRC.
Could this be the reason my nntp folders are all appearing to be empty?
(In reply to comment #22) > Could this be the reason my nntp folders are all appearing to be empty? I wouldn't expect that, this is done periodically, about every 5 minutes, but it is just about memory, not about local cache (unless it uncovered other bug). Please open a new bug report for your issue.
*** Bug 629804 has been marked as a duplicate of this bug. ***
I'm getting this crasher frequently, can this be backported to 2.32?
it should be there, based on comment #21, which says 2.31.1+
Hmm, I'm still seeing crashes. Maybe this isn't the same as #634285 after all.