https://bugs.kde.org/show_bug.cgi?id=339384
--- Comment #3 from Tim Ruffing <[email protected]> --- qDebug was not enabled for akonadi_kolab_resource. If I enable it, I get one more line (marked with >>>) akonadi_kolab_resource_1(10790)/kdepimlibs (kimap) KIMAP::LoginJob::handleResponse: "Login" "A000002" akonadi_kolab_resource_1(10790)/kdepimlibs (kimap) KIMAP::LoginJob::~LoginJob: KIMAP::LoginJob(0x11df050) akonadi_kolab_resource_1(10790) ImapResourceBase::doSetOnline: online= true akonadi_kolab_resource_1(10790)/libakonadi Akonadi::EntityListCache<T, FetchJob, FetchScope_>::processResult: "Item query returned empty result set" >>> akonadi_kolab_resource_1(10790) KolabHelpers::translateToImap: converted >>> event Qt has caught an exception thrown from an event handler. Throwing exceptions from an event handler is not supported in Qt. You must reimplement QApplication::notify() and catch all exceptions there. --- This happens in line 219 in kolabhelpers.cpp (v4.14.3). In a debug build, the "Q_ASSERT(item.hasPayload<KCalCore::Incidence::Ptr>());" (line 218) fires. So the expection is thrown while trying to access the payload afterwards. The reason is that a non-existing item is processed here. Query Debugger says: 21587: SELECT PimItemTable.id, PimItemTable.remoteId, MimeTypeTable.name, PimItemTable.rev, PimItemTable.remoteRevision, PimItemTable.size, PimItemTable.collectionId FROM PimItemTable INNER JOIN MimeTypeTable ON ( PimItemTable.mimeTypeId = MimeTypeTable.id ) WHERE ( ( PimItemTable.id = 86977 ) ) ORDER BY PimItemTable.id DESC Success: Query took 1 msecs Fetched 0 results Using debug output, I have confirmed that 86977 is the id of the item that fails in the assert. I just don't know where this id comes from, i.e., why this id should be accessed at all. It is possible that I created an item with this id (it's a "recent" id) locally, and deleted it afterwards, while I was offline. I could imagine that now it's still in some jon cache or similar for whatever reason, and the resource tries to send it to the kolab server. But I could not find the id anywhere in a table. (I don't know about caches.) As a workaround, I replaced the assert by if (!item.hasPayload<KCalCore::Incidence::Ptr>()) { ok = false; return Akonadi::Item(); } Using this modification, I could avoid the crash. Then akonadi_kolab_resource could start and sort things out. Afterwards, I reverted to the original version of akonadi_kolab_resource (that crashed beforehand). Now the problems seems to be solved for me. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. _______________________________________________ Kdepim-bugs mailing list [email protected] https://mail.kde.org/mailman/listinfo/kdepim-bugs
