Florian Weber wrote:
I now have done a more thorough check of this behaviour. I'm accessing my
folders in "Cached IMAP" mode (i.e. KMail keeps a local copy of everything).
When rebuilding the complete cache, KMail will hang on 6 folders out of about
60 at "25% finished". (Please don't ask me where that number comes from)
"hang" = keep waiting until the connection times out
So dbmail-imapd hangs up (segfault perhaps), and kmail times out. Makes sense.
"SELECT * FROM dbmail_messages" ---> 3801 rows
"SELECT * FROM dbmail_physmessage" --> 4512 rows
It is possible that the difference of 21 messages was cached during the first
run.
Mmm, normally it's the other way around: messages > physmessages. imap copy
would do that. There must be orphaned message data in your database. Some bug in
your message expiry code perhaps?
is it some specific message that's crashing dbmail-util?
So far the crashes are repeatable on one specific mail in one of the "hanging"
folders. Out of my gut Id expect crashes in the other "hanging" folders too.
I'll send you the offending mail in PM if you want it.
Yes. Binary exact copy in a gzip would be great.
Now about the backtrace: something strange is going on here. The backtrace is
not very useful (yes, I did compile with -g) (yes, when backtraced before the
crash bt'ing works fine):
(gdb) bt
#0 0xb7fcbed6 in list_prepend_node ()
from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/../../../libgmime-2.0.so.2
#1 0xb7fcb7ab in cache_node_insert ()
from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/../../../libgmime-2.0.so.2
#2 0x08080590 in ?? ()
#3 0x080963d8 in ?? ()
#4 0x080963d8 in ?? ()
You must be inside gmime/glib here. Which I guess wasn't compiled -g.
After singlestepping:
The problem is inside maintenance.c:672 [do_headercache()]
if (yes_to_all) {
672 -> if (db_set_headercache(lost) < 0) {
db_rollback_transaction();
qerrorf("Error caching the header values ");
has_errors = 1;
}
}
In this line, lost has a value that looks not abnormal to my eyes. It's
clearly the head of a linked list.
After *entering* db.c:db_set:_headercache (line 1447) lost suddenly is NULL.
Ok. Its a double free. lost is freed in db_set_headercache before returning an
error, while it's als called in the caller (maintenance.c) afterwards.
Fixed in the trunk.
--
________________________________________________________________
Paul Stevens mailto:[EMAIL PROTECTED]
NET FACILITIES GROUP PGP: finger [EMAIL PROTECTED]
The Netherlands________________________________http://www.nfg.nl
