Probably should also get added to one of the parser tests to make sure it doesn't fall on the face.

Talking about parser, I feel like this might benefit from highlighting somehow, currently it's very squished in with the random stuff in the header. That'll make it hard to search bugzilla for, globally, but also across different errors within the same application, as the only identifying element is $1 and I'm sure that's profoundly ambiguous as a search term. Admittedly the only way to improve it I can think of is print "Content of s_kcrashErrorMessage:"\nprint s_kcrashErrorMessage\n". The fact that this also prints empty messages doesn't exactly fill me with joy but I have no input on how to improve it either.

Application: dragon (dragon), signal: Segmentation fault
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
$1 = "!!! HALLO THIS IS A MESSAGE !!", '\000' <repeats 993 times>
[Current thread is 1 (Thread 0x7f255f320880 (LWP 19076))]

Thread 18 (Thread 0x7f250cff9700 (LWP 19093)):
#0  0x00007f255628d9f3 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x2544640) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1  __pthread_cond_wait_common (abstime=0x0, mutex=0

When this symbol isn't present, gdb just aborts and you don't get any back trace anymore:

Error in sourced command file:
No symbol "s_kcrashErrorMessage" in current context.