Created attachment 1103965 [details] small text fragment that exhibits the problem Description of problem: I tried to send a mail and evolution hung before sending, allocating memory like crazy (observed in top and strace). If I didn't interrupt it in time (2 or 3 times out of many attempts), it ate up so much memory eventually that X11/GNOME Shell stalled (mouse pointer didn't even move) for some minutes until swap was exhausted and evolution ran into a SIGSEGV (that one time I was patient enough to wait). This issue doesn't happen with the version in Fedora 23 GA, evolution-3.18.1-1.fc23.x86_64. Version-Release number of selected component (if applicable): evolution-3.18.2-1.fc23.x86_64 How reproducible: Reproducible Steps to Reproduce: 1. Start evolution, optionally configure a mail account 2. "New" (mail message) 3. Put in a recipient, subject 4. "Insert" -> "Text file..." -> (the attached evolution-send-broken.txt) 5. "Send" (or Ctrl+Return), confirm Actual results: Evolution allocates memory in a loop, eventually exhausting it if not killed/interrupted. The mail isn't sent at that point, nor appended to the sent mail folder. Expected results: Evolution sends the mail. Additional info: Here's what dmesg had to say about the segfault when memory ran out: [12029.780328] evolution[21772]: segfault at bbadbeef ip 00007f0c5c53357c sp 00007ffe1592b9e0 error 6 in libjavascriptcoregtk-3.0.so.0.16.17[7f0c5bf42000+714000] I could observe the phenomenon on my work machine (up-to-date, with many packages installed), as well as a newly setup Fedora 23 Workstation VM (installed via network, default pkg selection), with only evolution (and its dependencies) updated.
I've just bisected 3.18.1 .. 3.18.2 and found that this commit introduced this issue: https://git.gnome.org/browse/evolution/commit/?h=gnome-3-18&id=e7376ae73fdb67ef1755f9a3d3921d045c841abd commit e7376ae73fdb67ef1755f9a3d3921d045c841abd Author: Tomas Popela <tpopela> Date: Tue Oct 20 13:04:48 2015 +0200 EHTMLEditorView - Busy loop when replying to certain mail Avoid busy loop in the wrap_lines function when replying to [0]. The problem was that when we inserted the BR element before the actual node we didn't move we moved to the next node that was again the very same node. [0] - https://mail.gnome.org/archives/evolution-list/2015-October/msg00077.html