Bug 158753
| Summary: | [RHEL5] Evolution hang with message "Formatting message..." | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Doug Ledford <dledford> |
| Component: | evolution | Assignee: | Matthew Barnes <mbarnes> |
| Status: | CLOSED ERRATA | QA Contact: | |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | 5.0 | CC: | bnocera, jturner, mcrha, shillman, smithj4 |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | RHBA-2008-0361 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2008-05-21 15:17:35 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: | |||
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 Anyone working on fixing this bug? I am tired of killing evolution several times every day! 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?
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. Doug, how about you? Development Management has reviewed and declined this request. You may appeal this decision by reopening this request. 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. See also upstream: http://bugzilla.gnome.org/show_bug.cgi?id=352984 Clearing nacks/acks, and adding a tentative for RHEL 5.2.x 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. 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. 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. Based on comment #20, it sounds like this might be fixed by the rebase. Setting status to MODIFIED. 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 |
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.