Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 158753 - [RHEL5] Evolution hang with message "Formatting message..."
Summary: [RHEL5] Evolution hang with message "Formatting message..."
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: evolution
Version: 5.0
Hardware: All
OS: Linux
medium
high
Target Milestone: ---
: ---
Assignee: Matthew Barnes
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-05-25 13:25 UTC by Doug Ledford
Modified: 2008-05-21 15:17 UTC (History)
5 users (show)

Fixed In Version: RHBA-2008-0361
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-05-21 15:17:35 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2008:0361 normal SHIPPED_LIVE evolution bug fix and enhancement update 2008-05-20 18:03:46 UTC

Description Doug Ledford 2005-05-25 13:25:21 UTC
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 18:40:28 UTC
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 18:25:04 UTC
Anyone working on fixing this bug?  I am tired of killing evolution several
times every day!

Comment 8 Bastien Nocera 2005-11-04 17:04:38 UTC
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 19:23:13 UTC
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 14:14:59 UTC
Doug, how about you?

Comment 15 RHEL Product and Program Management 2006-07-21 16:27:53 UTC
Development Management has reviewed and declined this request.  You may appeal this decision by reopening this request.

Comment 17 Doug Ledford 2006-11-02 18:30:40 UTC
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 09:46:59 UTC
See also upstream:
http://bugzilla.gnome.org/show_bug.cgi?id=352984

Comment 19 Bastien Nocera 2007-07-03 14:00:53 UTC
Clearing nacks/acks, and adding a tentative for RHEL 5.2.x

Comment 20 Milan Crha 2007-09-11 12:52:01 UTC
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 15:34:50 UTC
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 20:33:52 UTC
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-21 04:29:47 UTC
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 15:17:35 UTC
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.