GNOME Bugzilla – Bug 583179
Evolution crashes when reading folder summary
Last modified: 2009-07-13 09:41:29 UTC
Steps to reproduce: After some Ubuntu updates (evolution 2.26.1-0ubuntu2), evolution started crashing on startup. Downgrading the package didn't help, so maybe upgrade was just a coincidence, so I am posting this here. Program received signal SIGSEGV, Segmentation fault. Stack trace:
+ Trace 215595
Thread 1 (Thread 0xb6155770 (LWP 9019))
Other information:
Or maybe this thread is guilty?
+ Trace 215596
Thread 15 (Thread 0xaf373b90 (LWP 9044))
It will be good if you can provide full traces.
Created attachment 135068 [details] full stacktrace of the crash always reproducible
Any ideas or workarounds? Milan, maybe you can help?
I guess those updates might be related. Try update all evolution-data-server, evolution, evolution-exchange to the latest versions, and it, with a bit of luck, will start to work. If not, what's on the console, when you run evolution there?
I am fully up-to-date, at least according to the Ubuntu maintainers. I can even reproduce the bug in evolution's offline mode: all I have to do is navigate to my Inbox folder, so this time it is not related to communication with the server, but probably with reading of some cached data from the disk. The console is not very informative: $ evolution --offline ** (evolution:5483): DEBUG: mailto URL command: evolution %s ** (evolution:5483): DEBUG: mailto URL program: evolution ** (evolution:5483): DEBUG: EI: SHELL STARTUP Segmentation fault (core dumped)
In that case, it seems your folders.db summary is heavily broken. What happens when you run this command, please: $ sqlite3 ~/.evolution/mail/exchange/<account>/folders.db "SELECT uid, flags, size, dsent, dreceived, subject, mail_from, mail_to, mail_cc, mlist, part, labels, usertags, cinfo, bdata FROM 'personal/Deleted Items' WHERE uid = '000002396d06'" (it's one long line, not 4; also, change there that <account> with the folder you've there). I guess it'll crash too, if yes, then move that folders.db file somewhere else (for debugging) and evolution will recreate it next start.
The renaming of folders.db helped - Evolution recreated it (although not yet fully - I have unchecked the 'check for mail in all folders' for now), and I can read my mail again. The select query above returns a perfectly normal result when executed from sqlite3. I wasn't able to find any corrupt records in the old folders.db. So it is still some weird evolution bug...
Would you mind to send me the broken folders.db in private (to the bugzilla mail), in some compress form, so I would try to look at its content for some simple corruptions I would think of? I really do not care for the message infos you've there (there are stored all the information shown in the message list tree (above the message preview, if you've turned that on).
Sent!
Thanks. Using your folders.db in my account also crashes evolution, though in a different folder, for me in Inbox. I found that there is a command for checking integrity of a folders.db file: $ sqlite3 folders.db "PRAGMA integrity_check;" and it is supposed to either return "ok" or list of errors, where for your file it returned: rowid 8199 missing from index sqlite_autoindex_personal/Inbox_1 rowid 13650 missing from index sqlite_autoindex_personal/Inbox_1 so I ran the reindex on it: $ sqlite3 folders.db "REINDEX 'personal/inbox';" and then even evolution was happy with the file. I guess the database corruption was caused by some previous evolution crash (as we are not using immediate writes with fsync calls now). I'm afraid that we cannot do more with this, nothing else then fix other bugs which causes crashes and could potentially break folders.db files. What do you think?
Thanks a lot for the investigation! As it probably would be hard to eliminate 100% all the causes when the db can be corrupted, maybe it makes sense to detect this corruption somehow and recreate the DB instead? Otherwise it is very hard for end-users to recover from such situation, making them think that evolution is too unstable for their use. I am just speculating here, do you have any idea how this kind of crash could be intercepted in the code? Maybe some logic in the signal handler?
(In reply to comment #12) > As it probably would be hard to eliminate 100% all the causes when the db can > be corrupted, maybe it makes sense to detect this corruption somehow and > recreate the DB instead? Yeah, that might be doable too, some integrity checks on start or something. I believe srag has something with this, in some other bug hopefully, thus CC'ing him here.
I recalled the same is discussed within bug #573125, thus marking this one as a duplicate. *** This bug has been marked as a duplicate of 573125 ***