[Akonadi] [Bug 339384] New akonadi_kolab_resource crashing (Signal: Aborted) on start up

[Tim Ruffing]

https://bugs.kde.org/show_bug.cgi?id=339384

--- Comment #3 from Tim Ruffing <public at timruffing.de> ---
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.