After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 573125 - Evolution crashes right after startup when having broken ~/.evolution
Evolution crashes right after startup when having broken ~/.evolution
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Mailer
2.30.x (obsolete)
Other Linux
: High critical
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
evolution[disk-summary] evolution[gno...
: 579973 582734 583179 589498 593216 593262 594756 604937 606701 619295 622356 626794 641865 (view as bug list)
Depends on:
Blocks: 543389
 
 
Reported: 2009-02-25 15:19 UTC by Tomas Bzatek
Modified: 2011-07-26 09:25 UTC
See Also:
GNOME target: ---
GNOME version: 2.29/2.30


Attachments
proposed eds patch (1.91 KB, patch)
2009-02-26 12:18 UTC, Milan Crha
reviewed Details | Review
Ted's more comprehensive patch. (3.64 KB, patch)
2010-01-03 19:55 UTC, Robert Collins
none Details | Review
eds patch (16.00 KB, patch)
2010-12-09 12:56 UTC, Milan Crha
committed Details | Review

Description Tomas Bzatek 2009-02-25 15:19:37 UTC
Note: this happens after recovery from RAID1 array crashdown, so data are in inconsistent state for sure... but evo still shouldn't crash.

evolution-2.25.91-1.fc11.x86_64
evolution-data-server-2.25.91-1.fc11.x86_64
evolution-spamassassin-2.25.91-1.fc11.x86_64
evolution-perl-2.25.91-1.fc11.x86_64



Distribution: Fedora release 10.91 (Rawhide)
Gnome Release: 2.25.91 2009-02-19 (Red Hat, Inc)
BugBuddy Version: 2.25.2

System: Linux 2.6.28-zen8 #1 SMP PREEMPT Mon Feb 9 16:38:56 CET 2009 x86_64
X Vendor: The X.Org Foundation
X Vendor Release: 10599903
Selinux: Enforcing
Accessibility: Disabled
GTK+ Theme: ClearlooksClassic
Icon Theme: Fedora
GTK+ Modules: canberra-gtk-module, gnomebreakpad

Memory status: size: 763351040 vsize: 763351040 resident: 30429184 share: 20529152 rss: 30429184 rss_rlim: 18446744073709551615
CPU usage: start_time: 1235574087 rtime: 47 utime: 42 stime: 5 cutime:0 cstime: 0 timeout: 0 it_real_value: 0 frequency: 100

Backtrace was generated from '/usr/bin/evolution'

[?1034h[Thread debugging using libthread_db enabled]
[New Thread 0x7ff535506910 (LWP 4531)]
[New Thread 0x7ff5377fe910 (LWP 4525)]
[New Thread 0x7ff537fff910 (LWP 4523)]
[New Thread 0x7ff53cfcc910 (LWP 4522)]
0x0000003f2b20f21f in waitpid () from /lib64/libpthread.so.0

Thread 4 (Thread 0x7ff537fff910 (LWP 4523))

  • #0 __lll_lock_wait
    from /lib64/libpthread.so.0
  • #1 _L_lock_1004
    from /lib64/libpthread.so.0
  • #2 pthread_mutex_lock
    from /lib64/libpthread.so.0
  • #3 <signal handler called>
  • #4 ____strtoull_l_internal
    from /lib64/libc.so.6
  • #5 read_uids_flags_callback
    at camel-db.c line 957
  • #6 sqlite3_exec
    at sqlite3.c line 69103
  • #7 camel_db_select
    at camel-db.c line 842
  • #8 camel_db_get_folder_uids_flags
    at camel-db.c line 979
  • #9 camel_folder_summary_load_from_db
    at camel-folder-summary.c line 966
  • #10 camel_imap_summary_new
    at camel-imap-summary.c line 210
  • #11 camel_imap_folder_new
    at camel-imap-folder.c line 260
  • #12 get_folder_offline
    at camel-imap-store.c line 2041
  • #13 get_folder
    at camel-imap-store.c line 1807
  • #14 camel_store_get_folder
    at camel-store.c line 345
  • #15 mail_tool_uri_to_folder
    at mail-tools.c line 331
  • #16 refresh_folders_exec
    at mail-send-recv.c line 819
  • #17 mail_msg_proxy
    at mail-mt.c line 520
  • #18 g_thread_pool_thread_proxy
    at gthreadpool.c line 265
  • #19 g_thread_create_proxy
    at gthread.c line 635
  • #20 start_thread
    from /lib64/libpthread.so.0
  • #21 clone
    from /lib64/libc.so.6
  • #22 ??


----------- .xsession-errors (15 sec old) ---------------------
warning: the debug information found in "/usr/lib/debug//lib64/libdl-2.9.90.so.debug" does not match "/lib64/libdl.so.2" (CRC mismatch).
warning: the debug information found in "/usr/lib/debug/lib64/libdl-2.9.90.so.debug" does not match "/lib64/libdl.so.2" (CRC mismatch).
(gnome-appearance-properties:4513): Gtk-WARNING **: Error loading theme icon 'gtk-missing-image' for stock: Error opening file: No such file or directory
(gnome-appearance-properties:4513): Gtk-WARNING **: Error loading theme icon 'gtk-missing-image' for stock: Error opening file: No such file or directory
(gnome-appearance-properties:4513): Gtk-WARNING **: Error loading theme icon 'gtk-missing-image' for stock: Error opening file: No such file or directory
(gnome-panel:4151): Gtk-WARNING **: Error loading theme icon 'gtk-missing-image' for stock: Error opening file: No such file or directory
--------------------------------------------------
Comment 1 Milan Crha 2009-02-26 12:18:08 UTC
Created attachment 129562 [details] [review]
proposed eds patch

for evolution-data-server;

I'm able to reproduce this by inserting manually an empty line to one folder's table in folders.db. These are places it crashed to me.
Comment 2 Matthew Barnes 2009-02-26 13:03:35 UTC
Just a thought, but if we can detect database corruption would it make sense to send up a user alert saying

  The message summary database for this account appears to be corrupted.
  Rebuilding the database should restore its integrity but may take some
  time.  Would you like to rebuild now?

                                 [ Do Not Rebuild ] [ Rebuild Database ]
Comment 3 Akhil Laddha 2009-03-05 03:36:04 UTC
please see bug 568539 , bug 574179 and mark them dupe if they are. Both are in exchange (mapi and owa connector) so i am not able to decide, thanks, 
Comment 4 Srinivasa Ragavan 2009-03-09 03:59:58 UTC
Matt, that would be a nice idea. Rebuilding index would be a better/wiser choice. Thoughts on how to detect DB corruption?
Comment 5 Matthew Barnes 2009-03-09 12:38:45 UTC
(In reply to comment #4)
> Matt, that would be a nice idea. Rebuilding index would be a better/wiser
> choice. Thoughts on how to detect DB corruption?

PRAGMA integrity_check and/or PRAGMA quick_check
http://www.sqlite.org/pragma.html#debug

The documentation claims 'quick_check' should run much faster, but I think it depends on the number of indexes in the database.  When I ran it on the database for my Red Hat IMAP account (by far my largest account), both commands took roughly three seconds.  Are we not using indexes in folders.db?

Not sure if SQLite blocks other database operations during an integrity check, or if -we- should, or if at least read operations are safe.  Need to research that more.  Ideally this could run in the background at startup and not block summary loading, because three seconds (probably more for mailing list hoarders) is a pretty noticable delay.

Also, should add a scrolled window to the rebuild dialog showing the actual integrity check errors, just to make it more scary looking.
Comment 6 Srinivasa Ragavan 2009-04-07 07:12:35 UTC
Sounds fine to me. May when the store is inited, we can check it. But not always IMO. May be we should time it. It would *block*, Infact, I have a 'vaccum' that I should also schedule. 

We index the tables for our usage. Most of the cols are indexed, except 1-2.

May be there should be an option evolution --rebuild-summary which should force it.

Comment 7 Milan Crha 2009-04-23 16:58:25 UTC
*** Bug 579973 has been marked as a duplicate of this bug. ***
Comment 8 Milan Crha 2009-05-21 18:05:09 UTC
*** Bug 582734 has been marked as a duplicate of this bug. ***
Comment 9 Milan Crha 2009-06-17 13:31:09 UTC
Srag, how is it going with your auto-vaccum? Though I see that will not help for these situations, neither the integrity_check, as with the table itself is nothing wrong, only some values are NULL. Thus I believe some test-before-use might be good to have there.
Comment 10 Srinivasa Ragavan 2009-06-20 14:33:16 UTC
Milan, I haven't got time for that yet. Ideally its just a mail_ops task that runs once a month or so, to vaccum the accounts. Thatz the model I want to take. This mail-ops task, should not be a start up task, but just a task starts a bit late or idle.

Comment 11 Milan Crha 2009-07-13 09:41:29 UTC
*** Bug 583179 has been marked as a duplicate of this bug. ***
Comment 12 Akhil Laddha 2009-07-24 03:27:37 UTC
*** Bug 589498 has been marked as a duplicate of this bug. ***
Comment 13 André Klapper 2009-08-08 12:42:10 UTC
Any news here? Patch available.
Comment 14 Akhil Laddha 2009-08-27 05:56:55 UTC
*** Bug 593216 has been marked as a duplicate of this bug. ***
Comment 15 Akhil Laddha 2009-08-28 03:52:16 UTC
*** Bug 593262 has been marked as a duplicate of this bug. ***
Comment 16 Olivier Berger 2009-08-28 08:44:53 UTC
Would anyone dare to comment on the patch, instead of spending time identifying duplicates of the bug ? ;-)
Comment 17 jwarnier 2009-09-15 11:13:28 UTC
Copy-paste of https://bugs.launchpad.net/evolution/+bug/339169:


Using http://www.gnome.org/~sragavan/evolution-rebuild-summarydb stated that my DB was corrupt:
$ ./evolution-rebuild-summarydb
Rebuilding Table ./local/folders.db
Rebuilding Table ./vfolder/folders.db
Rebuilding Table ./imap/jwarnier@mail.b.n/folders.db
SQL error: database disk image is malformed

I'm using IMAP, so all my e-mail is stored on the server. I then completely deleted my local cache directory: ~/.evolution/mail/imap/jwarnier@mail.b.be/.
I started Evolution, which resynchronized all my e-mail and is working again.

Hope it helps even more people.
Comment 18 Milan Crha 2009-12-18 21:31:55 UTC
*** Bug 604937 has been marked as a duplicate of this bug. ***
Comment 19 Milan Crha 2009-12-18 21:32:44 UTC
The above bug #604937 contains more extended patch.
Comment 20 Robert Collins 2010-01-03 19:50:48 UTC
So this crash occurs when the uid or flags field is NULL; I haven't checked but I suspect that the rows are inserted and then later updated, so a crash between those transactions can create this situation without any sqlite level corruption. The callback has to be changed to handle NULL fields.
Comment 21 Robert Collins 2010-01-03 19:53:58 UTC
Oh, and the larger patch - http://bugzilla-attachments.gnome.org/attachment.cgi?id=150013 - is definitely the one to apply AFAICT. Meta: It seems nuts to me to close the patch with the better patch as the dup :). I'll link Ted's patch here to make it more accessible.
Comment 22 Robert Collins 2010-01-03 19:55:34 UTC
Created attachment 150750 [details] [review]
Ted's more comprehensive patch.
Comment 23 Akhil Laddha 2010-06-22 07:59:43 UTC
*** Bug 622356 has been marked as a duplicate of this bug. ***
Comment 24 André Klapper 2010-08-13 13:11:10 UTC
*** Bug 626794 has been marked as a duplicate of this bug. ***
Comment 25 Milan Crha 2010-10-01 13:10:50 UTC
*** Bug 619295 has been marked as a duplicate of this bug. ***
Comment 26 Milan Crha 2010-12-09 09:31:54 UTC
*** Bug 594756 has been marked as a duplicate of this bug. ***
Comment 27 Milan Crha 2010-12-09 09:39:10 UTC
*** Bug 606701 has been marked as a duplicate of this bug. ***
Comment 28 Milan Crha 2010-12-09 12:56:35 UTC
Created attachment 176129 [details] [review]
eds patch

for evolution-data-server;

I merged idea from the above patches and from the patch from bug #606701, plus added a few of my ideas to it too, and this is the result. There are also a follow up changes in evolution-exchange and evolution-mapi, which I'm not going to attach here, but simply commit them. (They are using new API functions instead of EXTRACT_... macros.)
Comment 29 Milan Crha 2010-12-09 13:01:06 UTC
Created commit ceb9060 in eds master (2.91.4+)
Created commit 7566563 in eex master (2.91.4+)
Created commit 8db2654 in ema master (2.91.4+)
Comment 30 Milan Bouchet-Valat 2010-12-09 15:11:59 UTC
Really great to see that old and weird bugs like that get fixed eventually! ;-)
Comment 31 Fabio Durán Verdugo 2011-02-09 00:09:12 UTC
*** Bug 641865 has been marked as a duplicate of this bug. ***
Comment 32 Milan Crha 2011-07-26 09:25:41 UTC
Downstream bug report about the same from 2.32.2:
https://bugzilla.redhat.com/show_bug.cgi?id=720010