On Friday 08 April 2005 19:08, Paul J Stevens wrote:
> Could you perhaps run it through gdb and provide me with a backtrace?
/me is confused.
See at bottom
> > Ok. Found [4491] un-cached physmessages.
> > Segmentation fault
> Definitely a bug.
At last! That's the first time a problem wasn't due to my stupidity :o)
> > I am quite puzzled: did I actually find a bug (would be my first time
> > *g*) or am I missing something obvious? Interestingly, IMAP and LMTP
> > access work flawlessly *except* for one folder. (POP is untested)
> Please explain the part about the one folder that doesn't work.
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
One of the folders I see the hang on contains the message that will make
dbmail-util crash.
> 2.1.0 is untested on postgresql-8. I've only tested 7.4.7. Not that I
> expect it to be relevant, though.
Well, you've got your first tester :-)
> > - a few 10,000 messages in the DB
> This doesn't add up. dbmail-util reports 4491 uncached physmessages, but
You're right, it doesn't. My limits for deleting old mails were much tighter
than I thought when estimating that number. To be exact:
"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.
> 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.
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 ?? ()
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.
From there on, everything goes down the drain with execution (or just gdb?)
jumping around inside db_set_headercache 'till dbmail-util crashes.
Would a core image help you?
--
With best regards,
Florian Weber
