GNOME Bugzilla – Bug 634285
[abrt] Crash in cfs_try_release_memory()
Last modified: 2015-03-10 17:26:06 UTC
Moving this from a downstream bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=650269 abrt version: 1.1.13 architecture: i686 Attached file: backtrace cmdline: evolution component: evolution crash_function: cfs_try_release_memory executable: /usr/bin/evolution kernel: 2.6.35.6-48.fc14.i686 package: evolution-2.32.0-2.fc14 rating: 4 reason: Process /usr/bin/evolution was killed by signal 11 (SIGSEGV) release: Fedora release 14 (Laughlin) time: 1288973870 uid: 500 How to reproduce ----- 1. using mouse pointer on scroll bar Core was generated by `evolution'. Program terminated with signal 11, Segmentation fault.
+ Trace 224555
Thread 1 (Thread 9859)
I got similar crash in master (2.91.3) (evolution:2901): camel-CRITICAL **: camel_folder_get_parent_store: assertion `CAMEL_IS_FOLDER (folder)' failed Program received signal SIGSEGV, Segmentation fault. 0xb7b62b79 in cfs_try_release_memory (s=0xa9b491a0) at camel-folder-summary.c:1569 1569 session = CAMEL_SERVICE (parent_store)->session; (gdb) t a a bt
+ Trace 225072
Thread 1 (Thread 0xb5ff9830 (LWP 2901))
error = 0x0 (gdb) l 1564 s->timeout_handle = 0; 1565 return FALSE; 1566 } 1567 1568 parent_store = camel_folder_get_parent_store (s->folder); 1569 session = CAMEL_SERVICE (parent_store)->session; 1570 1571 if (time (NULL) - s->cache_load_time < SUMMARY_CACHE_DROP) 1572 return TRUE; 1573 (gdb) p s->folder $1 = (struct _CamelFolder *) 0x8a5a6c0 (gdb) p *s->folder $2 = {parent = {parent = {g_type_instance = {g_class = 0xaa1a0820}, ref_count = 3476802158, qdata = 0xaaaaaaaa}, priv = 0xaaaaaaaa}, priv = 0xaaaaaaaa, summary = 0xaaaaaaaa, folder_flags = 2863311530, permanent_flags = -1431655766, later = {0xaaaaaaaa, 0xaaaaaaaa, 0xaaaaaaaa, 0xaaaaaaaa}} (gdb) p G_OBJECT_TYPE_NAME(s) No symbol "G_OBJECT_TYPE_NAME" in current context. (gdb) p *s $3 = {parent = {parent = {g_type_instance = {g_class = 0x847d658}, ref_count = 4, qdata = 0x0}, priv = 0xa9b49230}, priv = 0xa9b49238, version = 14, flags = 0, nextuid = 6, time = 0, saved_count = 5, unread_count = 0, deleted_count = 0, junk_count = 0, junk_not_deleted_count = 0, visible_count = 5, message_info_chunks = 0x0, content_info_chunks = 0x0, summary_path = 0x8497308 "/home/lakhil/.local/share/evolution/mail/maildir/.Copy.ev-summary", build_content = 0, uids = 0x89f51b0, loaded_infos = 0x91edb50, folder = 0x8a5a6c0, meta_summary = 0x89b76d8, cache_load_time = 1291966949, timeout_handle = 160745, collate = 0x0, sort_by = 0xad6b25ae "dreceived", later = {0x0, 0x0, 0x0, 0x0}} (gdb) p s->parent.parent.g_type_instance $4 = {g_class = 0x847d658} (gdb) p *s->parent.parent.g_type_instance.g_class $5 = {g_type = 138925088} (gdb) p g_type_name(s->parent.parent.g_type_instance.g.Type struct _GTypeInstance has no component named g. (gdb) p *s->parent.parent.g_type_instance.g_class.g_type $6 = 15 (gdb) p g_type_name(s->parent.parent.g_type_instance.g_class.g_type) $7 = (gchar *) 0xad6b2590 "CamelMaildirSummary"
Hrm, I cannot reproduce this, neither when cheating the code (by lowering eds/camel/camel-folder-summary.c:SUMMARY_CACHE_DROP to say 5 seconds). The above shows that the summary survived its folder, and from the code it seems that is not possible unless something reffed the folder->summary somewhere and forgot to unref it again (forgot or something else failed before it was able to unref it). So we depend on actual operation here, which is causing this. I see it's doing on a regular maildir folder, named Copy in Akhil's case. The problem is that I do not know how to track this down at the moment. Maybe if some steps are available, the best in offline mode...
Hm. Is there any way to reproduce this issue?
*** Bug 648092 has been marked as a duplicate of this bug. ***
I'm getting this frequently with 2.32 and maildirs. I can replicate by simply having evolution open and doing nothing. (gdb) bt
+ Trace 226800
$1 = (CamelFolderSummary *) 0x7fa323d299b0 (gdb) print *s $2 = {parent = {parent = {g_type_instance = {g_class = 0x7fa323d26860}, ref_count = 228, qdata = 0x0}, priv = 0x7fa323d29ab0}, priv = 0x7fa323d29ac0, version = 14, flags = 0, nextuid = 2, time = 0, saved_count = 680, unread_count = 0, deleted_count = 588, junk_count = 0, junk_not_deleted_count = 0, visible_count = 92, message_info_chunks = 0x0, content_info_chunks = 0x0, summary_path = 0x7fa323b21f90 "/home/ross/Mail/LinuxIntel/Linux.ev-summary", build_content = 0, uids = 0x7fa323fd1160, loaded_infos = 0x7fa3236fbd90, folder = 0x7fa323e079c0, meta_summary = 0x7fa323b20490, cache_load_time = 1303298074, timeout_handle = 145, collate = 0x0, sort_by = 0x7fa30319d840 "dreceived", later = {0x0, 0x0, 0x0, 0x0}}
(In reply to comment #2) > Hrm, I cannot reproduce this, neither when cheating the code (by lowering > eds/camel/camel-folder-summary.c:SUMMARY_CACHE_DROP to say 5 seconds). The > above shows that the summary survived its folder, and from the code it seems > that is not possible unless something reffed the folder->summary somewhere and > forgot to unref it again (forgot or something else failed before it was able to > unref it). So we depend on actual operation here, which is causing this. > > I see it's doing on a regular maildir folder, named Copy in Akhil's case. > > The problem is that I do not know how to track this down at the moment. Maybe > if some steps are available, the best in offline mode... Milan, I think the vfolders ref the summary, but not the folder and I don't see how it unrefs it when the folder dies. Checkup camel-vee-summary.c:camel_vee_summary_add Ross's vfolders are off, but still trash/junk could cause this. Ross: to confirm, can you empty trash & delete/expunge junk and see if you can reproduce the bug?
I'd love to, but if I try to expunge my maildirs then evolution locks up.
*** Bug 648513 has been marked as a duplicate of this bug. ***
*** Bug 649163 has been marked as a duplicate of this bug. ***
Hmm, I just got this with IMAP folder in git master (before 3.5.3) with the below backtrace. The console showed: (evolution:31850): camel-CRITICAL **: camel_folder_get_parent_store: assertion `CAMEL_IS_FOLDER (folder)' failed (evolution:31850): camel-CRITICAL **: camel_service_get_session: assertion `CAMEL_IS_SERVICE (service)' failed
+ Trace 230336
Thread 1 (Thread 0x7f2bd02b0a00 (LWP 31850))
Bad, I cannot reproduce it now. I tried to debug this and it seems fine. I see only one possible issue, that is the disable of the cfs_try_release_memory() callback, which is done only in finalize, while most of the internal (priv) members are gone in dispose. I do not know whether that is the case, but it might be. I committed changes for this, and I'm closing this bug too. I'll reopen (or you please do) in case I/you'll be able to reproduce this again. Created commit ec57923 in eds master (3.5.3+) Created commit be57410 in eds gnome-3-4 (3.4.3+)
Reopening, downstream bug report from 3.4.3: https://bugzilla.redhat.com/show_bug.cgi?id=853174
+ Trace 230766
Thread 1 (Thread 0x7f24c913d9c0 (LWP 1710))
One similar downstream bug report from 3.8.3 involving evolution-ews: https://bugzilla.redhat.com/show_bug.cgi?id=983678
+ Trace 232229
Thread 1 (Thread 0xb7451900 (LWP 2315))
Even in 3.10.0: https://bugzilla.redhat.com/show_bug.cgi?id=1013217
No duplicate for a long time, I'm closing this.