Summary: | Assert in IMAP resource ("!set.toImapSequenceSet().trimmed().isEmpty()") [KIMAP::FetchJob::setSequenceSet, RetrieveItemTask::triggerFetchJob, RetrieveItemTask::onSelectDone] | ||
---|---|---|---|
Product: | [Frameworks and Libraries] Akonadi | Reporter: | Alex Merry <alex.merry> |
Component: | IMAP resource | Assignee: | Christian Mollekopf <chrigi_1> |
Status: | RESOLVED FIXED | ||
Severity: | crash | CC: | andresbajotierra, kdepim-bugs, rakuco, vkrause, winter |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Alex Merry
2010-12-14 02:14:43 UTC
Actually, the crash happens when I start kmail. Every time, now, since the change conflict loop happened and the unread count for one of the folders got stuck. Restarting akonadi didn't change anything. The crash also happens when I open the folder with the bad unread message count in akonadiconsole. I can't find a message without the \SEEN flag in akonadiconsole, although I've only looked through some of the messages (including the thread of the message that caused trouble previously). [Comment from a bug triager] From bug 260680: - What I was doing when the application crashed: I was using KMail2, and when I clicked one of my IMAP folders the Akonadi resource crashed (the new folder loaded correctly, though). kdelibs: r1207605 kdepimlibs: r1207605 kdepim: r1207605 *** Bug 260680 has been marked as a duplicate of this bug. *** I've just experienced this same problem and was able to reproduce the crash -- it happens every time I try to enter the IMAP folder with the conflicting message in KMail2. To debug that kind of cases efficiently, I'd need to be provided with some idea of the IMAP traffic which created the issue. That can be done by setting the KIMAP_LOGFILE environment variable and restarting the akonadiserver. For instance: export KIMAP_LOGFILE=imaplog akonadictl restart Look at the pid of the imap resource you should then have a couple of imaplog.pid.* files. Wait for the crash, and then provide me what happened before the crash. It's the best way for me to create a test case that I can reproduce here. Only caveat though is that some private data is likely in the log (except the authentication phase, after that it logs everything) so you'd have to trust me with your data and send it privately. Also I would need some more information of the structure of the conflicting messages on the akonadi side, using akonadiconsole perhaps? The IMAP resource has a new maintainer, reassigning to him. I haven't seen this issue for a few years now. I'm happy for this bug to be closed as unreproducible. |