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
#0 __strtol_internal (nptr=0x82143f8 "", endptr=0x82a2b98, base=0,
#1 0x080edc74 in KDialog::marginHint () at eval.c:41
#2 0x40c232db in QObject::activate_signal ()
#3 0x40c22d32 in QObject::destroyed () from
#4 0x40c209b1 in QObject::~QObject () from
#5 0x40c66a9f in QWidget::~QWidget () from
#6 0x40bda356 in QDialog::~QDialog () from
#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)
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>
Fixed in 2.2-0.cvs20010513.1