Bug 158753 - [RHEL5] Evolution hang with message "Formatting message..."
[RHEL5] Evolution hang with message "Formatting message..."
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: evolution (Show other bugs)
5.0
All Linux
medium Severity high
: ---
: ---
Assigned To: Matthew Barnes
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-05-25 09:25 EDT by Doug Ledford
Modified: 2008-05-21 11:17 EDT (History)
5 users (show)

See Also:
Fixed In Version: RHBA-2008-0361
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-21 11:17:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Doug Ledford 2005-05-25 09:25:21 EDT
Description of problem: On occasion, when clicking on an email in a folder (the
folder itself is a local mail folder, but it's over NFS), the program will get
to the point of displaying the status message "Formatting message..." and then
will never get any further.  When this happens, the program starts to use 100%
CPU resources.  Sometimes, going to the Actions menu and selecting Empty Trash
will break it out of this loop.  If that doesn't work, the only option is to
shut down evolution entirely and restart it.


Version-Release number of selected component (if applicable):
evolution-2.0.2-16


How reproducible:
Happens about once per day

Steps to Reproduce:
1. Have mail filtered into local folders
2. Have local folders actually reside on an NFS server
3. Use it and wait for it to happen
  
Actual results:
Hangs.

Expected results:
Should format and display the message.

Additional info:
Doing an strace of evolution when it was in the looping state showed this:

poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=8,
events=POLLIN|POLLPRI}, {fd=10, events=POLLIN}, {fd=12, events=POLLIN|POLLPRI},
{fd=24, events=POLLIN}, {fd=41, events=POLLIN, revents=POLLHUP}, {fd=20,
events=POLLIN}, {fd=22, events=POLLIN}], 9, 84) = 1
gettimeofday({1116947075, 712834}, NULL) = 0
ioctl(3, FIONREAD, [0])                 = 0
gettimeofday({1116947075, 712962}, NULL) = 0
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=8,
events=POLLIN|POLLPRI}, {fd=10, events=POLLIN}, {fd=12, events=POLLIN|POLLPRI},
{fd=24, events=POLLIN}, {fd=41, events=POLLIN, revents=POLLHUP}, {fd=20,
events=POLLIN}, {fd=22, events=POLLIN}], 9, 79) = 1

Notice that the poll call is returning with an event on file descriptor 41
(POLLHUP), but that evolution is evidently not checking that and instead is
assuming that the file descriptor associated with the message retrieval,
probably fd 3, must have data and is attempting to read the data, but there's
nothing there, so it polls again ad infinitum.  The program should A) check that
the poll event is on the expected descriptor and not another descriptor and B)
if it isn't on the expected descriptor it should handle the event (especially
since handling the event seems to be required before the event that it is
waiting on will occur, so possibly fd 41 is a control channel between evolution
and the evolution data server while fd 3 is the data channel or something like
that).

Of special note, on occasion killing evolution to clear this problem out
corrupts the mailbox.  At this point, evolution will no longer start on my
machine because it crashes while creating the message counts for the vfolders,
and that started happening after killing evolution to clear out the exact
instance of this bug that I straced.  That's why I set priority to High, this
has the potential to corrupt mailboxes.
Comment 2 Jason Smith 2005-06-27 14:40:28 EDT
I also see evolution hang several times a day with the "Formatting message..."
text in the bottom notify area, but I don't see it using 100% of the CPU.  Any
word on a possible fix in the next update?

~Jason
Comment 3 Jason Smith 2005-08-02 14:25:04 EDT
Anyone working on fixing this bug?  I am tired of killing evolution several
times every day!
Comment 8 Bastien Nocera 2005-11-04 12:04:38 EST
I can reproduce this bug, and managed to get a half-decent backtrace.

Thread 9 (Thread -1242600528 (LWP 688)):
#0  0x0094e7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0x00bb0a86 in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib/tls/libpthread.so.0
#2  0x02ad3bc9 in do_get_contacts (sync=1, book=0xafd5bdd0, query=0xfffffffc,
    contacts=0xb5ef5d60, error=0xb5ef5d64, cb=0xfffffffc, closure=0xfffffffc)
    at e-book.c:1803
#3  0x02ad8222 in e_book_get_contacts (book=0xafd5bdd0, query=0xafd89060,
    contacts=0xb5ef5d60, error=0xb5ef5d64) at e-book.c:1841
#4  0x03b2280e in em_utils_in_addressbook ()
   from /usr/lib/evolution/2.0/components/libevolution-mail.so
#5  0x03b0d5eb in em_format_html_job_queue ()
   from /usr/lib/evolution/2.0/components/libevolution-mail.so
#6  0x03b0eeab in em_format_html_job_queue ()
   from /usr/lib/evolution/2.0/components/libevolution-mail.so
#7  0x03b388c2 in mail_enable_stop ()
   from /usr/lib/evolution/2.0/components/libevolution-mail.so
#8  0x0294a285 in e_thread_busy () from /usr/lib/evolution/2.0/libeutil.so.0
#9  0x00bae341 in start_thread () from /lib/tls/libpthread.so.0
#10 0x00a2e6fe in clone () from /lib/tls/libc.so.6

I believe the problem is:
- you have an LDAP and/or Exchange addressbook
- you have set "Load images" for your HTML mail based on the presence of the
sender in your addressbook.

Does that match your configurations?
Comment 9 Jason Smith 2005-11-04 14:23:13 EST
I checked my evolution settings and you are 100% correct, I have both a work
ldap server configured for my contact address book, and the "Load images if
sender is in address book" option set.
Comment 10 Bastien Nocera 2005-11-05 09:14:59 EST
Doug, how about you?
Comment 15 RHEL Product and Program Management 2006-07-21 12:27:53 EDT
Development Management has reviewed and declined this request.  You may appeal this decision by reopening this request.
Comment 17 Doug Ledford 2006-11-02 13:30:40 EST
I had an ldap addressbook at one time yes, and I don't see this issue with my
current setup that doesn't include ldap in my searched address books, so that
could be the cause.
Comment 18 Bastien Nocera 2006-11-03 04:46:59 EST
See also upstream:
http://bugzilla.gnome.org/show_bug.cgi?id=352984
Comment 19 Bastien Nocera 2007-07-03 10:00:53 EDT
Clearing nacks/acks, and adding a tentative for RHEL 5.2.x
Comment 20 Milan Crha 2007-09-11 08:52:01 EDT
I can not reproduce this bug on actual evolution (2.11.92) completely. I turned
on those options and walked through mail. The preview stuck only when there was
"Formating message..." and "Retrieving message xxx", but not for longer than 5
seconds (usually after it retrieved message, it takes minimum time to format
message - less than one second). It never stuck completely on my machine, even
the lack was noticeable with options turned on. I also noticed that Evolution
remembers all the messages I step on during time of waiting for reply from the
net, and after the freeze end it shows all the messages I stepped on, even I was
couple of massages after them.
Comment 21 Matthew Barnes 2007-09-11 11:34:50 EDT
To clarify Milan's comment, we're rebasing Evolution to the soon-to-be-release
version 2.12 for RHEL 5.2, so we're testing RHEL bugs against the latest
development release from upstream.
Comment 24 RHEL Product and Program Management 2007-10-19 16:33:52 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 27 Matthew Barnes 2007-11-20 23:29:47 EST
Based on comment #20, it sounds like this might be fixed by the rebase.

Setting status to MODIFIED.
Comment 33 errata-xmlrpc 2008-05-21 11:17:35 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2008-0361.html

Note You need to log in before you can comment on or make changes to this bug.