Bug 488391

Summary: evolution hangs forever reading spool mbox
Product: [Fedora] Fedora Reporter: John Mellor <john.mellor>
Component: evolutionAssignee: Matthew Barnes <mbarnes>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: low    
Version: 10CC: mbarnes, mcrha
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-12-18 08:56:42 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
evolution --debug output while experiencing the bug none

Description John Mellor 2009-03-04 02:04:11 UTC
Created attachment 333963 [details]
evolution --debug output while experiencing the bug

Description of problem:
Evolution hangs with errors displayed on bottom bar when reading mbox mail.  Mail was perfectly ok prior to upgrading to this latest evolution version.  Spool is verified correct, and can be read with mailx and vi.
Evolution must be killed to recover.  Problem is 100% repeatable, rendering evolution completely useless.

Version-Release number of selected component:
evolution-2.24.5-1.fc10.i386

How reproducible:


Steps to Reproduce:
1. open evolution
2. click on localhost mbox mail, with 2 known messages in it
3. note 2 error messages on bottom of panel about corrupt folder:
   a. "Error while refreshing folder"
   b. "stuck message about retrieving message 375 (...)"
  
Actual results:
evolution hung, consuming small amount of cpu forever.
No known tools to recover from this defect.

Expected results:
normal mail operation

Additional info:
evolution --debug evo.dbg
logfile attached.

Comment 1 Milan Crha 2009-03-04 09:55:07 UTC
It tries to rebuild index files automatically, but fails for you for some reason. Could you install debug info packages for evolution and evolution-data-server, and when it gets to this "eating CPU, but doing nothing" state, attach gdb to running evolution process and attach here result of gdb command "thread apply all bt", please?

After that, as a workaround, try to follow description in this link:
http://www.go-evolution.org/FAQ#Why_do_I_get_an_error_.22Summary_and_folder_mismatch.2C_even_after_a_sync.22.3F

but do not delete those files, just move them elsewhere. It would be good to have them backed up, for testing. Also look for folders.db file there and get it out too.

Comment 2 John Mellor 2009-03-05 02:21:38 UTC
I tried following the advise in this 2006 Ubuntu bug report:
    https://lists.ubuntu.com/archives/desktop-bugs/2006-January/012931.html
followed by this Suse bug workaround:
    http://www.averyjparker.com/2006/08/08/evolution-error-summary-and-folder-mismatch-even-after-a-sync/

but I still had the summary mismatch problem.

In desperation, I followed a 2007 Ubuntu forum rant about the same situation, and deleted the local mbox mail account completely in evolution, exited, manually deleted *all* of the directory tree (which was left after deleting the account - a secondary bug) in:
    .evolution/mail/spool/var/spool/mail/$LOGNAME
and then restarted evolution and added the local mbox account back in.

Voila!  Evolution now works properly again!  The mbox contents were still there, and perfectly readable.

Unfortunately I did this before the request for the preservation of the broken evolution files was posted.  Sorry!

So the bug appears to be that for whatever reason, the summary and something else get mismatched from reality and no recovery is attempted, leaving evolution in an unstable and probably unusable state.  [Putting on my grey hat: That is an unacceptable fragility caused by excessive application complexity for the task.  There are probably hundreds of way to trigger this scenario, most of which have not been designed for]

However, all is not lost.  Evolution is smart enough to detect that this impossible situation has occurred, as it pops up a totally useless error message about it.  Instead of just complaining that it is broken, fault-handling code needs to be added so that when a situation like this is detected, evolution should take a few seconds and throws away its index and summary files, and rebuild them, just like Lotus Notes and Exchange do.

If this code cannot be added into the fault handler reasonably, then perhaps it could be put into a simple bash, perl or python script which could be invoked manually to at least give the user some kind of tool like IBM's ZapNotes utility to at least allow a support organization to recover for the non-hacker end-user.

Comment 3 Piergiorgio Sartor 2009-04-23 07:58:41 UTC
I have, probably, the same issue, but under different conditions.

I normally use "mutt" to read emails, but sometimes I need/like to use evolution.

Since F10, if the mbox file (/var/spool/mail/<user>) is changed (by mutt) evolution behaves like explained in this bug report.
It hangs while complaining the mbox does not match the internal indexes.

This is new, since until F9 it was working fine, i.e. I could process emails with mutt and with evolution, not together, of course.

So, it seems something got lost in some update/upgrade.

It would be nice, in general, to have evolution a bit robust against this kind of "corruption" of the mbox file.

Thanks,

pg

Comment 4 Piergiorgio Sartor 2009-05-20 12:31:28 UTC
Actually, I somehow solved the problem...

I just installed "dovecot", the IMAP server, configured to provide only IMAP (or IMAPs, no POP3 nor POP3s, this to avoid mbox file modifications) and to listen only to localhost.

Then I configured "evolution" (and "thunderbird") to use the IMAP protocol with localhost.

With this setup, everything works really fine.

This does not fix the "evolution" bug, but I hope it could help nevertheless.

pg

Comment 5 Bug Zapper 2009-11-18 09:29:07 UTC
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 6 Bug Zapper 2009-12-18 08:56:42 UTC
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.