GNOME Bugzilla – Bug 565237
crash in camel/providers/imap/camel-imap-folder.c:imap_sync()
Last modified: 2013-08-19 13:50:22 UTC
0) evolution (presumably) crashed while my system thawed from hibernate. Actually a very short session of evolution, basically: start evolution -> do very little -> hibernate -> thaw -> crash 1) backtrace (gdb) bt
+ Trace 210984
2) offending code: (gdb) l 1451 1452 if (expunge) 1453 imap_expunge (folder, ex); 1454 1455 /* Check if the replay is already in progress as imap_sync would be called while expunge resync */ 1456 if (!CAMEL_IMAP_JOURNAL (imap_folder->journal)->rp_in_progress) { 1457 CAMEL_IMAP_JOURNAL (imap_folder->journal)->rp_in_progress = TRUE; 1458 1459 camel_offline_journal_replay (imap_folder->journal, ex); 1460 camel_imap_journal_close_folders ((CamelIMAPJournal *)imap_folder->journal); 3) tail of stdout and/or stderr: [...] (evolution:2762): calendar-gui-WARNING **: gnome-cal.c:918: Could not create the query: Backend is busy (evolution:2762): calendar-gui-WARNING **: gnome-cal.c:918: Could not create the query: Backend is busy (evolution:2762): calendar-gui-WARNING **: gnome-cal.c:918: Could not create the query: Backend is busy (evolution:2762): calendar-gui-WARNING **: gnome-cal.c:918: Could not create the query: Backend is busy (evolution:2762): calendar-gui-WARNING **: gnome-cal.c:918: Could not create the query: Backend is busy (evolution:2762): calendar-gui-WARNING **: gnome-cal.c:918: Could not create the query: Backend is busy (evolution:2762): calendar-gui-WARNING **: gnome-cal.c:918: Could not create the query: Backend is busy (evolution:2762): calendar-gui-WARNING **: gnome-cal.c:918: Could not create the query: Backend is busy (evolution:2762): Gtk-WARNING **: GtkSpinButton: setting an adjustment with non-zero page size is deprecated (evolution:2762): Gtk-WARNING **: GtkSpinButton: setting an adjustment with non-zero page size is deprecated (evolution:2762): Gtk-WARNING **: GtkSpinButton: setting an adjustment with non-zero page size is deprecated (evolution:2762): Gtk-WARNING **: GtkSpinButton: setting an adjustment with non-zero page size is deprecated (evolution:2762): calendar-gui-CRITICAL **: e_day_view_add_event: assertion `end > add_event_data->day_view->lower' failed (evolution:2762): calendar-gui-WARNING **: Couldn't find event window (evolution:2762): Gtk-WARNING **: GtkSpinButton: setting an adjustment with non-zero page size is deprecated (evolution:2762): camel-WARNING **: Trying to check junk data is OBJECT 'CamelFolder' (evolution:2762): camel-CRITICAL **: camel_object_is: assertion `check_magic(o, ctype, CAMEL_OBJECT_MAGIC)' failed (evolution:2762): camel-CRITICAL **: camel_folder_sort_uids: assertion `CAMEL_IS_FOLDER (folder)' failed (evolution:2762): camel-WARNING **: Trying to check junk data is OBJECT 'CamelIMAPJournal' (evolution:2762): camel-CRITICAL **: camel_object_cast: assertion `check_magic(o, ctype, CAMEL_OBJECT_MAGIC)' failed Segmentation fault (core dumped) 4) quick analysis: CAMEL_IMAP_JOURNAL (imap_folder->journal) seems to be "translated" to: (CamelIMAPJournal *) camel_object_cast ((CamelObject *) imap_folder->journal, (CamelType) camel_imap_journal_get_type()) camel_object_cast() has returned NULL here: [...] 1070 g_return_val_if_fail(check_magic(o, ctype, CAMEL_OBJECT_MAGIC), NULL); [...] which made the "CAMEL_IMAP_JOURNAL (imap_folder->journal)->rp_in_progress" pointer invalid. I'm not at all sure what to do about this: could and should evolution-data-server handle this in another way than crashing? Neither am I sure what to do about the preceding (apparent) problem in imap_sync(), here: [...] 1338 camel_folder_sort_uids (folder, summary); [...]
0) A straightforward and totally _untested_ way the prevent this crash would simply be: diff -up evolution-data-server-2.25.2/camel/providers/imap/camel-imap-folder.c.565237 evolution-data-server-2.25.2/camel/providers/imap/camel-imap-folder.c --- evolution-data-server-2.25.2/camel/providers/imap/camel-imap-folder.c.565237 2008-11-27 10:41:04.000000000 +0100 +++ evolution-data-server-2.25.2/camel/providers/imap/camel-imap-folder.c 2008-12-21 13:21:41.000000000 +0100 @@ -1453,7 +1458,7 @@ imap_sync (CamelFolder *folder, gboolean imap_expunge (folder, ex); /* Check if the replay is already in progress as imap_sync would be called while expunge resync */ - if (!CAMEL_IMAP_JOURNAL (imap_folder->journal)->rp_in_progress) { + if (CAMEL_IMAP_JOURNAL (imap_folder->journal) && !CAMEL_IMAP_JOURNAL (imap_folder->journal)->rp_in_progress) { CAMEL_IMAP_JOURNAL (imap_folder->journal)->rp_in_progress = TRUE; camel_offline_journal_replay (imap_folder->journal, ex); 1) A naive and equally _untested _ solution to the preceding (apparent) problem mentioned in 4) of comment #0 would be: diff -up evolution-data-server-2.25.2/camel/providers/imap/camel-imap-folder.c.565237 evolution-data-server-2.25.2/camel/providers/imap/camel-imap-folder.c --- evolution-data-server-2.25.2/camel/providers/imap/camel-imap-folder.c.565237 2008-11-27 10:41:04.000000000 +0100 +++ evolution-data-server-2.25.2/camel/providers/imap/camel-imap-folder.c 2008-12-21 13:21:41.000000000 +0100 @@ -1308,15 +1308,20 @@ imap_sync_offline (CamelFolder *folder, static void imap_sync (CamelFolder *folder, gboolean expunge, CamelException *ex) { - CamelImapStore *store = CAMEL_IMAP_STORE (folder->parent_store); + CamelImapStore *store; CamelImapMessageInfo *info; - CamelImapFolder *imap_folder = CAMEL_IMAP_FOLDER (folder); + CamelImapFolder *imap_folder; CamelException local_ex; GPtrArray *matches, *summary; char *set, *flaglist, *uid; int i, j, max; + + g_return_if_fail (CAMEL_IS_FOLDER (folder)); + store = CAMEL_IMAP_STORE (folder->parent_store); + imap_folder = CAMEL_IMAP_FOLDER (folder); + if (folder->permanent_flags == 0 || CAMEL_OFFLINE_STORE (store)->state == CAMEL_OFFLINE_STORE_NETWORK_UNAVAIL) { if (expunge) { imap_expunge (folder, ex); 2) Feedback appreciated.
This isn't disk summary related. This is due to chen's migration to CamelOfflineFolder
*** Bug 578332 has been marked as a duplicate of this bug. ***
(In reply to comment #2) > This isn't disk summary related. This is due to chen's migration to > CamelOfflineFolder srag, I believe Paul had very different idea about a comment :) Paul, do you remember/can you check whether the 'folder' pointer is invalid or NULL please?
(In reply to comment #4) > Paul, do you remember/can you check whether the 'folder' pointer is invalid or > NULL please? I remember next to nothing about this crash. I even have trouble understanding my own analysis! Anyway, I was surprised to find that core file still on a disk (of my previous, not yet discarded test machine): [~]$ ls -n core.2762 -rw------- 1 500 500 82653184 2008-12-21 10:34 core.2762 [~]$ file core.2762 core.2762: ELF 32-bit LSB core file Intel 80386, version 1 (SYSV), SVR4-style, from 'evolution' A small problem is that I had already upgraded both evolution, evolution-data-server and their debuginfo rpms to newer versions on that machine. Is there a way to still use that core file? Or do we know what version of evolution and evolution-data-server rawhide shipped on December 21, 2008 and can I still grab those (with their debuginfo rpms) from some archive?
I'm afraid the actual snap will not be of much use, only for checking NULL/not NULL (which I asked first, that's right). The preferable way is to have some reproducer, or debug logs to check when such thing happens. I saw some similar info with hibernation, not sure if your case at all. Do we talk about fedora rawhide?
(In reply to comment #6) > I'm afraid the actual snap snap? > will not be of much use, only for checking NULL/not > NULL (which I asked first, that's right). The preferable way is to have some > reproducer, or debug logs to check when such thing happens. I saw some similar > info with hibernation, not sure if your case at all. You mean that what you actually like is a way to reproduce this crash? > Do we talk about fedora rawhide? Yes, my test machine was running (then) current rawhide.
(In reply to comment #7) > (In reply to comment #6) > > I'm afraid the actual snap > > snap? snap as a 'crash dump', snap of the actual state of the crash. > > will not be of much use, only for checking NULL/not > > NULL (which I asked first, that's right). The preferable way is to have some > > reproducer, or debug logs to check when such thing happens. I saw some similar > > info with hibernation, not sure if your case at all. > > You mean that what you actually like is a way to reproduce this crash? Yeah, definitely, as I believe some steps leads to this. > > Do we talk about fedora rawhide? > > Yes, my test machine was running (then) current rawhide. Then try to look in http://koji.fedoraproject.org/koji/packages
(In reply to comment #8) > Then try to look in http://koji.fedoraproject.org/koji/packages Thanks. On koji i found the packages that were installed when this crash happened (as my yum.log showed me) and installed those (force to use "rpm -Uvh * --nodeps --force") Core was generated by `evolution'. Program terminated with signal 11, Segmentation fault.
+ Trace 214521
$1 = {parent_object = {klass = 0x9e6ac18, magic = 0, hooks = 0x9e6b0e0, ref_count = 0, flags = 1, next = 0x0, prev = 0x0}, priv = 0xb6b811f8, name = 0xb58b53d8 "", full_name = 0xb6b81248 "h\307E\265il]/Trash", description = 0x0, parent_store = 0x997e020, summary = 0x9e6c580, folder_flags = 3, permanent_flags = 2147485855, later = { 0x0, 0x0, 0x0, 0x0}} So folder wasn't NULL (but folder->full_name does look strange ...). Anything else you'd like to know?
note that ref_count = 0 in the log. Seems like a wrong pointer in place, or a dead folder.
If it works fine, but only not after hibernation, then what can be wrong on evo side? Just in case, give here also "t a a bt", please, to see the whole context of the crash. Thanks.
Not much additional things to see here, I'd say. (These backtraces miss a lot of debugging symbols. At this point I assume it's not useful to try to downgrade all relevant debuginfo rpms for Fedora's rawhide to their version as of December 20, 2008.) (gdb) t a a bt
+ Trace 214538
Thread 1 (Thread 3163)
*** Bug 580414 has been marked as a duplicate of this bug. ***
*** Bug 598283 has been marked as a duplicate of this bug. ***
Closing as OBSOLETE since the legacy IMAP backend was retired in 3.8.