GNOME Bugzilla – Bug 259496
Backend seems to crash when reading certain HTML-formatted e-mails.
Last modified: 2013-09-10 13:41:38 UTC
Distribution: Mandrake Linux release 10.0 (Official) for i586 Package: Evolution-Data-Server Priority: Major Version: GNOME2.4.1 unspecified Gnome-Distributor: MandrakeSoft Synopsis: Backend seems to crash when reading certain HTML-formatted e-mails. Bugzilla-Product: Evolution-Data-Server Bugzilla-Component: Mailer Bugzilla-Version: unspecified Description: Description of the crash: While browsing through e-mails, evolution appears to get 'stuck' on a particular message, refusing to update the preview pane when I select another message. I can still double-click on a message to open it explicitly in a new window, and I can switch freely to other components. On coming back to the mail-reader, however, the preview pane remains stuck. Shutting down and restarting the shell fixes the problem until I attempt to read the message again. Steps to reproduce the crash: I haven't been able to determine a way of consistently reproducing, but it seems to be reacting to certain conditions in an email; if I find one that causes it to freeze, it will consistently freeze whenever I try to read that email. Expected Results: Preview view does not freeze. How often does this happen? Every time, with specific emails. Additional Information: So far, it seems that this only happens on HTML-formatted emails. A subjective analysis suggests that an image is being loaded, as I have had it freeze part-way through loading the images for an email. However, I have had it freeze most often on several spam emails, where it should not be attempting to load images (I have the "Load images only if contact is in addressbook" enabled), so while it does seem to be related to HTML processing, I can't say that it's due to image loading and/or rendering. I suspect that it is also happening with emails I read in a separate window, but it does not appear to demonstrate the same problems (the shell allows me to close and reopen the message window freely, so I can't tell if it's 'freezing'). I don't know for certain that the debugging information shown here is specifically related to this problem, but every time it happens, I get a new core dump file. Debugging Information: Backtrace was generated from '/usr/libexec/evolution-data-server-1.0' Using host libthread_db library "/lib/i686/libthread_db.so.1". Core was generated by `/usr/libexec/evolution-data-server-1.0 --oaf-activate-iid=OAFIID:GNOME_Evolutio'. Program terminated with signal 6, Aborted.
+ Trace 47012
Thread 1 (process 3885)
the backtrace is worthless. can you attach a sample message? I'm wondering if this is just an incarnation of the pango bug that's been bitting us for months now.
Created attachment 43806 [details] Sample e-mail
ok, the message is not the scrensaver-in-an-iframe bug I was thinking of.
Incidentally, I'm pretty sure I never saw this error pre-1.5.7, if that helps. Oddly, though, I only saw it in the Mandrakelinux packaged versions of 1.5.7, although I have seen this in both the Ximian and Mandrakelinux packages for 1.5.8.
Feels like the pango crash. Actually I'm unable to reproduce this using the attached mail. Can you get an evolution (not e-d-s) backtrace? If you need help creating one please check http://support.ximian.com/q?65
gerardo: it's not.
The documented instructions on creating a backtrace seem to be relevant to earlier versions of evolution, when the threading was still handled as separated tasks/processes/whatever. Are these instructions still valid for 1.5.8? If so, which component would I be running through gdb, anyway? Also, I will have to wait 'til I get home to do this, as I don't have a ready cache of e-mails here that are known to crash it; I'll try to get something up by Sat.
David: yea, the instructions are somewhat outdated. You'll want to run evolution-1.5 under gdb and when it crashes, you'll want to use "thread apply all bt" to get a backtrace. I'm not gonna bother marking as NEEDINFO yet since you've attached an example message. Hopefully next week either I or Michael will get a chance to test this. If we can't reproduce th crash, then we'll need that backtrace - otherwise we probably won't (altho it never hurts to attach one if you can).
David: does it freeze with a "Formating message" in notification area?
Yes, it did; however, the main shell still operates just fine--I can switch freely to other components, but when I switch back to Mail, the preview window still shows the frozen message. However, I just upgraded to 1.5.9.1-1mdk, and the crash seems to have stopped; It still fails to load images, but it no longer freezes on a message, nor am I getting core dump files. Interestingly, I had one message that it stalled on, appearing to crash, but a while later it managed to complete loading it; perhaps it's a timeout issue of some sort? If I can get my other copy to crash, I'll definitely send in the debugging info (that's the copy at work, where I just don't seem to get the types of email that cause the problem). I'll try importing the posted message when I get a chance, though, see if it happens here.
Created attachment 43830 [details] Backtrace of Evolution 1.5.8 (evolution1.5-1.5.8.0.200405260819-0.snap.ximian.7.1)
I imported the sample message that I uploaded earlier, and waited until it seemed to freeze; then broke into gdb and generated the backtrace. As before, I've got a new core dump file in my home dir; should I be debugging the data server instead, as that's the part that seems to keep crashing? If so, how do I run it separately?
aha. the infamous addressbook query hang. I think that toshok was actually looking for a backtrace for this this morning. now he can have one! muhahaha!
Took me a moment to figure that one out "What does *that* have to do with loading images?" Then it hit me. "Of course, it's querying the addressbook to see if it needs to load images! D'oh!" Glad to help out; the thought of going back to Outlook was making me cringe. Guess I should (temporarily) set it to "Load all images" to see if the problem goes away ... Hmm. Can't verify if "Never load" works (looks like it's locally caching, so any images already loaded show up regardless of the setting, even through a restart), but I set it to "Always load" and it looks like it works beautifully; no lockups, no freezing. Whoo!
I'm going to mark this duplicate of the base report (bug 256479) and add a note there for this (precious) backtrace. *** This bug has been marked as a duplicate of 256479 ***