I should add that after re-opening Evolution I was asked whether I wanted to restore the email. Doing this I got the whole mail text back but no image was attached (this was the last thing I did before trying to send it, which resulted in the crash). I then attached the exact same image again and hit send and this time the email went out without any problems, so the bug is, unfortunately, not reproducible.

Thanks for a bug report. It's better to paste backtraces inline, or at least the crashing thread, thus it's significantly easier to search for them later. It's also recognized by bugzilla itself and it can eventually notify you about possible duplicates (I'm adding the crashing thread below).

Your crash looks pretty close to bug #773420, thus I'm marking this as a duplicate of it. That bug report is closed, due to lack of reproducer (which, unfortunately, happened here as well).

+ Trace 237492

*** This bug has been marked as a duplicate of bug 773420 ***

Ok, thanks for the clarification about pasting backtraces.

It just happened again. This time while sending an email without any attachment after clicking on "Edit as new Message" of a previously sent email, then changing the recipient address and making a small change in the text of the email. The backtrace was:

Thread 1 "evolution" received signal SIGSEGV, Segmentation fault.
strlen () at ../sysdeps/x86_64/strlen.S:106
106	../sysdeps/x86_64/strlen.S: No such file or directory.
(gdb) backtrace 

+ Trace 237496

Just before the crash I noticed that sending took unusually long to complete and in top I could see some Webkit process taking up 100% of CPU for an extended amount of time. Then the crash happened and after restarting Evolution and recovering the email, the body of the email was empty. Repeating the same steps made the email go out normally.

While I cannot deterministically reproduce this, it seems likely that it will happen again in the future. Can you tell me what additional information I can provide the next time the crash happens that would help you resolve the issue?

(In reply to Christian Gogolin from comment #3)
> Just before the crash I noticed that sending took unusually long to complete
> and in top I could see some Webkit process taking up 100% of CPU for an
> extended amount of time. Then the crash happened and after restarting
> Evolution and recovering the email, the body of the email was empty.

That's it, the WebKitWebProcess got stuck on something, then the call to retrieve message body timed out due to it, and it resulted into the crash. The fix in the other bug doesn't cause the crash, but also lefts message body as empty.

If you could, and I do not know whether there will be enough time for it, then capture backtrace of that stuck (high-CPU-using) WebKitWebProcess, which will show what it does. I see you have already installed debuginfo for evolution, which should be sufficient (debuginfo for WebKitGTK+ is huge and usually not needed, thus please avoid it for now; it can also break gdb bakctrace capturing in some situations).

By the way, are all your messages HTML? With or without inline images? Any signatures also in HTML? With or without inline images? This seems to be data-specific and very sensitive on the data itself. I recall that spellchecker could get crazy sometimes, also blocking the web process, but it wasn't a busy-loop block, if I recall correctly.

Some version of WebKit could also get stuck in hyphenation. If it is the thing you face or not I do not know. it's filled here:
https://bugs.webkit.org/show_bug.cgi?id=165601

What it is will show the backtrace of the WebKitWebProcess.

Great looks like there is a chance to nail this one down.

I have hacked together the following bash script 

#!/bin/bash                                                                                                                                                                           

load=0
i=0
threshold=90.0
dt=0.1
num=5
while true
do
    sleep $dt
    ret=$(ps -eo pid -eo pcpu -eo command | grep WebKitWebProcess | sort -k 2 -r | head -n 1 | awk '{print $1, $2}')
    pid=$(echo $ret | awk '{print $1}')
    load=$(echo $ret | awk '{print $2}')
    echo "$pid causes $load"
    st=`echo "$load > $threshold" | bc`
    if [ $st -eq 1 ]
    then
        i=$i+1  
        echo "load high $i"
    else
        i=0
        echo "load low"
    fi
      
    if [[ $i -gt $num ]]
    then
        gdb -p "$pid" -ex cont
    fi
done


that monitors the resource usage of WebKitWebProcesses and launches attaches gdb if the exceed 90% load for more than a second and immediately continues execution. I will be running this on the side and hope that it triggers at some point.

I suppose that Evolution kills the process after the timeout and that then gdb will ask me for input? What shall I do than? Is a simple "backtrace" enough for you?

Both messages for which I observed the problem were HTML without inline images and plain text signatures. The first had an image attached.

Okay. First of all, why did you reopen the bug report? Please do not do that, I do read comments on closed bugs too, as you might notice earlier. You just caused unnecessary noise and mess due to the reopen. I will reopen this, if it will be needed (but I'll rather reference the older bug in any follow-up changes). We can do further investigation here, I'm all fine with it.

(In reply to Christian Gogolin from comment #5)
> I suppose that Evolution kills the process after the timeout and that then
> gdb will ask me for input?

I do not know, I do not think evolution kills anything on purpose, the WebKitWebProcess is fully handled by WebKitGTK+ without any direct evolution intervention.

> What shall I do than?

Waiting for the process to be stopped is too late. I need backtrace when the process is stuck, not when it's stopped. A backtrace of all threads would be fine as the started, like "t a a bt" command in gdb.

Ideally, when you notice higher CPU usage and evolution looking like being stuck on something, then that's the time when capture the backtrace of the corresponding WebKitWebProcess. The thing is there are always at least two such processes. One for message preview(s), another for message composer(s). The one for composers automatically goes away when all composers are closed and is created when the first composer window is opened (it's shared between all composer instances).

*** This bug has been marked as a duplicate of bug 773420 ***