GNOME Bugzilla – Bug 606344
Clicking "Reply to All" button causes Evo to dump core
Last modified: 2013-09-13 01:03:36 UTC
Created attachment 150995 [details] mbox format of bad message I'm using Evo built from the latest GIT (as of just an hour or two ago) and if I click "Reply to All" on a certain message, Evo dumps core on me. My account uses IMAP. This might be a problem in gtkhtml (that's where the core seems to be) but I only started having this problem (that I know of) recently and I haven't changed gtkhtml in a while. It seems to be Evo incorrectly closing a gtkhtml stream, or something. Let me know if you think it really belongs in gtkhtml. Note I can "Reply to All" with other messages and it works. I haven't been able to determine if there are other messages that fail and if so, what the common denominator is. Interestingly, it's a message that was posted to evolution-list just today; archived here: http://mail.gnome.org/archives/evolution-list/2010-January/msg00041.html I'll add the raw message as an attachment. Here's the stack trace info:
+ Trace 219955
(gdb) l 175 /* XXX Should we log errors that are not cancellations? */ 176 177 html = GTK_HTML (request->web_view); 178 stream = request->output_stream; 179 180 gtk_html_end (html, stream, GTK_HTML_STREAM_ERROR); 181 web_view_request_free (request); 182 g_error_free (error); 183 184 return TRUE;
FYI it also happens on plain "Reply" and "Reply to List", not just "reply to all". It appears to be something about the contents of the reply (I have HTML mail enabled, and quoting). Also, if I just select some of the text and then hit reply, it doesn't dump core. Only if I try to reply where the entire message is quoted.
I can reproduce it with your test message as well. Thus confirming.
Question for Matt: Why is composer EWebView? Reason: ASYNC doesn't work here, as there is no connection on stream closing, and the EWebView obviously doesn't know how to get embedded images from message body, whereas the composer knows how to do that. And it did that actually, but as the second in a row, web view put its async fetch in a queue first, but the stream got freed just after that, and then one got an error of wrong URI, and then web view tried to close GtkHtmlStream which was already closed. Making composer plain GtkHTML fixes the issue. (e-msg_composer.c:2275)
Fixed in two commits: http://git.gnome.org/browse/evolution/commit/?id=7636c4705148cd31f842de134448918381dc2045 http://git.gnome.org/browse/gtkhtml/commit/?id=203ce61e6ea19323914b9c459b2e79bde5db15be It was a signal handler ordering issue. See the first commit message for a detailed explanation.
(In reply to comment #3) > Question for Matt: Why is composer EWebView? Two reasons: 1) to eliminate duplicate code in EWebView and GtkhtmlEditor, and 2) I'm trying to hide as much direct GtkHTML usage as possible behind the EWebView API to help prepare for the migration to WebKit.
*** Bug 606161 has been marked as a duplicate of this bug. ***
Works now; thanks Matt!