For me the problem did not show up immediately after switching to the new Kolab ressource. The new ressource worked for some weeks... Now it crashes reliably.

the output is:
[...]
akonadi_kolab_resource_1(8051)/kdepimlibs (kimap) KIMAP::LoginJob::handleResponse: "Login" "A000002"
akonadi_kolab_resource_1(8051)/kdepimlibs (kimap) KIMAP::LoginJob::~LoginJob: KIMAP::LoginJob(0x1121f80)
akonadi_kolab_resource_1(8051)/libakonadi Akonadi::EntityListCache<T, FetchJob, FetchScope_>::processResult: "Item query returned empty result set" 
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.

terminate called after throwing an instance of 'Akonadi::PayloadException'
  what():  Akonadi::PayloadException: No payload set
KCrash: Application 'akonadi_kolab_resource' crashing...
KCrash: Attempting to start /usr/lib/kde4/libexec/drkonqi from kdeinit
KCrash: Connect sock_file=/home/tim/.kde4/socket-calzone/kdeinit4__0
Unregistering search instance "akonadi_kolab_resource_1" 
Lost connection to resource "org.freedesktop.Akonadi.Resource.akonadi_kolab_resource_1" , discarding cached interface 
void Akonadi::Server::NotificationSource::serviceUnregistered(const QString&) Notification

---

Application: [...] of type Kolab Groupware Server (akonadi_kolab_resource), signal: Aborted
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[Current thread is 1 (Thread 0x7f0b7aa587c0 (LWP 8051))]

Thread 2 (Thread 0x7f0b63539700 (LWP 8053)):
#0  0x00007f0b758747bd in poll () from /usr/lib/libc.so.6
#1  0x00007f0b747f7c94 in ?? () from /usr/lib/libglib-2.0.so.0
#2  0x00007f0b747f7dac in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#3  0x00007f0b7a094397 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#4  0x00007f0b7a063de1 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#5  0x00007f0b7a064145 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#6  0x00007f0b79f587f9 in QThread::exec() () from /usr/lib/libQtCore.so.4
#7  0x00007f0b79f5b05f in ?? () from /usr/lib/libQtCore.so.4
#8  0x00007f0b74edd314 in start_thread () from /usr/lib/libpthread.so.0
#9  0x00007f0b7587d5bd in clone () from /usr/lib/libc.so.6

Thread 1 (Thread 0x7f0b7aa587c0 (LWP 8051)):
[KCrash Handler]
#5  0x00007f0b757c8a97 in raise () from /usr/lib/libc.so.6
#6  0x00007f0b757c9e6a in abort () from /usr/lib/libc.so.6
#7  0x00007f0b75daefcd in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/libstdc++.so.6
#8  0x00007f0b75dace56 in __cxxabiv1::__terminate(void (*)()) () from /usr/lib/libstdc++.so.6
#9  0x00007f0b75dacea1 in std::terminate() () from /usr/lib/libstdc++.so.6
#10 0x00007f0b75dad106 in __cxa_rethrow () from /usr/lib/libstdc++.so.6
#11 0x00007f0b7a06434b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#12 0x00007f0b7a0696e9 in QCoreApplication::exec() () from /usr/lib/libQtCore.so.4
#13 0x00007f0b7a56006c in Akonadi::ResourceBase::init(Akonadi::ResourceBase*) () from /usr/lib/libakonadi-kde.so.4
#14 0x00000000004314fe in _start ()

forgot to add:

This is KDE 4.14.3 on Arch Linux (x86_64).

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.

This bug has never been confirmed for a KDE PIM version that is based on KDE Frameworks (5.x). Those versions differ significantly from the old 4.x series. Therefore, I plan to close it in around two or three months. In the meantime, it is set to WAITINGFORINFO to give reporters the oportunity to check if it is still valid. As soon as someone confirms it for a recent version (at least 5.1, ideally even more recent), I'll gladly reopen it.

Please understand that we lack the manpower to triage bugs reported for versions almost two years beyond their end of life.

Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.1 aka 15.12; preferably much more recent), please open a new one unless it already exists. Thank you for all your input.