Description of Problem:

Following is the bug report filed with bugs.kde.org.

I'm seeing what is most likely the same bug, manifested as death by SEGV:
   
1. start kmail as "kmail user-to-send-to".
2. you can add --composer if you want, it doesn't matter.
3. send the mail.
4. kmail will crash and burn on the way down (after sending the mail);
this is a destructor problem.
  
I haven't recompiled it yet, but with just the symbols I've got it may be 
helpful:

(gdb) bt
#0  __strtol_internal (nptr=0x82143f8 "", endptr=0x82a2b98, base=0,
group=0)
    at eval.c:36
#1  0x080edc74 in KDialog::marginHint () at eval.c:41
#2  0x40c232db in QObject::activate_signal ()
   from /usr/lib/qt-2.3.0/lib/libqt.so.2
#3  0x40c22d32 in QObject::destroyed () from
/usr/lib/qt-2.3.0/lib/libqt.so.2
#4  0x40c209b1 in QObject::~QObject () from
/usr/lib/qt-2.3.0/lib/libqt.so.2
#5  0x40c66a9f in QWidget::~QWidget () from
/usr/lib/qt-2.3.0/lib/libqt.so.2
#6  0x40bda356 in QDialog::~QDialog () from
/usr/lib/qt-2.3.0/lib/libqt.so.2
#7  0x080ebead in KDialog::marginHint () at eval.c:41
#8  0x0815a3a7 in KDialog::marginHint () at eval.c:41
#9  0x0815b885 in KDialog::marginHint () at eval.c:41
#10 0x41111177 in __libc_start_main (
    main=0x815b4c0 <KDialog::marginHint(void)+993532>, argc=5,
    ubp_av=0xbffff5fc, init=0x806269c <_init>, fini=0x818e640 <_fini>,
    rtld_fini=0x4000e184 <_dl_fini>, stack_end=0xbffff5ec)
    at ../sysdeps/generic/libc-start.c:129
(gdb)

And another data point that may help: I went to reproduce this to get the
trace while I was writing this message, and could not. That is, if a kmail
instance is already active, then starting another instance (thread?) by
the above procedure does not result in a crash; it works perfectly. Only
if we are creating a new kmail instance that goes directly into the
composer do we get a SEGV.

The above chain looks like it had a problem walking the destructor list,
possibly on the way out of the composer dialog. Let me know if you still
need a better traceback or if this is enough to locate the problem. FWIW,
this could be a QT problem, if the trace is somewhat accurate; attempting
to examine the params to __strtol_internal gives results that indicate
that the stack might have been smashed by this point.
(gdb) p nptr
$1 = 0x1e0020 <Address 0x1e0020 out of bounds>
(gdb) p *nptr
Cannot access memory at address 0x1e0020
(gdb) p endptr
$2 = (char **) 0x80edc40
(gdb) p *endptr
$3 = 0x83e58955 <Address 0x83e58955 out of bounds>