Can you check in the debug output if the online state changed just before it crashed?
You should see a message in doSetOnline ("online=...."),

dfaure reported a disconnect just before a similar crash, so let's assume that's the cause.
This happens due to the CollectionFetchJob that is not aborted on disconnect, so we need to fix that.

Created attachment 88644 [details]
debug info by dfaure

I suppose this version of the crash could be explained if for some reason the the task was killed (although we don't see a disconnect), and the batchfetcher continued afterwards. I.e. the abortActivity codepath disconnects the sessions which in turns triggers cancelTask in ResourceTask (thus ending the task). However, the internal BatchFetcher job continues to run as it only get's deleted once the session is deleted. Further both the session and the task are deleted via deleteLater, meaning the BatchFetcher still gets a chance to issues a signal through the ResourceTask that then triggers itemsRetrieved (resulting in a crash since cancelTask has already been called).

Similar BT for me

#1  0x00007f34e891cd3a in abort () from /usr/lib/libc.so.6
#2  0x00007f34ed1161c4 in qt_message_output (msgType=QtFatalMsg, 
    buf=0x7f34e0dea818 "ASSERT failure in createItemSyncInstance: \"Calling items retrieval methods although no item retrieval is in progress\", file /data/extra2/sources/kde-master/kde/kdepimlibs/akonadi/resourcebase.cpp, lin"...) at global/qglobal.cpp:2359
#3  0x00007f34ed116343 in qt_message(QtMsgType, const char *, typedef __va_list_tag __va_list_tag *) (msgType=QtFatalMsg, msg=0x7f34ed2e0330 "ASSERT failure in %s: \"%s\", file %s, line %d", ap=0x7fff2719c8f8)
    at global/qglobal.cpp:2405
#4  0x00007f34ed116b15 in qFatal (msg=0x7f34ed2e0330 "ASSERT failure in %s: \"%s\", file %s, line %d") at global/qglobal.cpp:2588
#5  0x00007f34ed115dc3 in qt_assert_x (where=0x7f34edaa97cd "createItemSyncInstance", what=0x7f34edaa9468 "Calling items retrieval methods although no item retrieval is in progress", 
    file=0x7f34edaa9040 "/data/extra2/sources/kde-master/kde/kdepimlibs/akonadi/resourcebase.cpp", line=174) at global/qglobal.cpp:2062
#6  0x00007f34eda1b493 in Akonadi::ResourceBasePrivate::createItemSyncInstanceIfMissing (this=this@entry=0x7f34e0f35cc0) at /data/extra2/sources/kde-master/kde/kdepimlibs/akonadi/resourcebase.cpp:173
#7  0x00007f34eda180ed in Akonadi::ResourceBase::itemsRetrieved (this=<optimized out>, items=...) at /data/extra2/sources/kde-master/kde/kdepimlibs/akonadi/resourcebase.cpp:1166
#8  0x0000000000440745 in RetrieveItemsTask::onItemsRetrieved (this=0x7f34dac07e80, addedItems=...) at /data/extra2/sources/kde-master/kde/kdepim-runtime/resources/imap/retrieveitemstask.cpp:493
#9  0x00007f34ed27c28e in QMetaObject::activate (sender=0x7f34e0ca6480, m=0x478380 <BatchFetcher::staticMetaObject>, local_signal_index=0, argv=0x7fff2719cc00) at kernel/qobject.cpp:3567
#10 0x0000000000457b80 in BatchFetcher::itemsRetrieved (this=this@entry=0x7f34e0ca6480, _t1=...) at /data/extra2/sources/kde-master/build/kde/kdepim-runtime/resources/imap/moc_batchfetcher.cpp:111
#11 0x000000000045c399 in BatchFetcher::onHeadersReceived (this=0x7f34e0ca6480, mailBox=..., uids=..., sizes=..., attrs=..., flags=..., messages=...)
    at /data/extra2/sources/kde-master/kde/kdepim-runtime/resources/imap/batchfetcher.cpp:188
#12 0x00000000004588f3 in BatchFetcher::qt_static_metacall (_o=0x5af3, _c=23283, _id=6, _a=0xffffffffffffffff) at /data/extra2/sources/kde-master/build/kde/kdepim-runtime/resources/imap/moc_batchfetcher.cpp:60
#13 0x00007f34ed27c28e in QMetaObject::activate (sender=0x7f34d64e4c60, m=0x6a5b40 <KIMAP::FetchJob::staticMetaObject>, local_signal_index=1, argv=0x7fff2719ce80) at kernel/qobject.cpp:3567
#14 0x00007f34eb8ddf73 in KIMAP::FetchJob::headersReceived (this=0x7f34d64e4c60, _t1=..., _t2=..., _t3=..., _t4=..., _t5=..., _t6=...)
    at /data/extra2/sources/kde-master/build/kde/kdepimlibs/kimap/moc_fetchjob.cpp:137
#15 0x00007f34eb8e2f91 in KIMAP::FetchJobPrivate::emitPendings (this=0x7f34e0fd3740) at /data/extra2/sources/kde-master/kde/kdepimlibs/kimap/fetchjob.cpp:71
#16 0x00007f34eb8df817 in KIMAP::FetchJob::handleResponse (this=0x7f34d64e4c60, response=...) at /data/extra2/sources/kde-master/kde/kdepimlibs/kimap/fetchjob.cpp:286
#17 0x00007f34eb8ef2e0 in KIMAP::SessionPrivate::responseReceived (this=0x7f34e0e8f3c0, response=...) at /data/extra2/sources/kde-master/kde/kdepimlibs/kimap/session.cpp:300
#18 0x00007f34ed275bdb in QMetaCallEvent::placeMetaCall (this=0x7f34d65112e0, object=0x7f34e0e8f3c0) at kernel/qobject.cpp:524
#19 0x00007f34ed276e5f in QObject::event (this=0x7f34e0e8f3c0, e=0x7f34d65112e0) at kernel/qobject.cpp:1222
#20 0x00007f34ec0c04dc in QApplicationPrivate::notify_helper (this=0x7f34e0c4e380, receiver=0x7f34e0e8f3c0, e=0x7f34d65112e0) at kernel/qapplication.cpp:4562
#21 0x00007f34ec0bda78 in QApplication::notify (this=0x7fff2719dfb0, receiver=0x7f34e0e8f3c0, e=0x7f34d65112e0) at kernel/qapplication.cpp:3944
#22 0x00007f34e9e44551 in KApplication::notify (this=0x7fff2719dfb0, receiver=0x7f34e0e8f3c0, event=0x7f34d65112e0) at /data/extra2/sources/kde-master/kde/kdelibs/kdeui/kernel/kapplication.cpp:311
#23 0x00007f34ed25dd03 in QCoreApplication::notifyInternal (this=0x7fff2719dfb0, receiver=0x7f34e0e8f3c0, event=0x7f34d65112e0) at kernel/qcoreapplication.cpp:953
---Type <return> to continue, or q <return> to quit---
#24 0x00007f34ed2619fd in QCoreApplication::sendEvent (receiver=0x7f34e0e8f3c0, event=0x7f34d65112e0) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:231
#25 0x00007f34ed25ed30 in QCoreApplicationPrivate::sendPostedEvents (receiver=0x0, event_type=0, data=0x7f34e0c35080) at kernel/qcoreapplication.cpp:1577
#26 0x00007f34ed25e953 in QCoreApplication::sendPostedEvents (receiver=0x0, event_type=0) at kernel/qcoreapplication.cpp:1470
#27 0x00007f34ec18d9f1 in QCoreApplication::sendPostedEvents () at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:236
#28 0x00007f34ec199577 in QEventDispatcherX11::processEvents (this=0x7f34e0c37130, flags=...) at kernel/qeventdispatcher_x11.cpp:75
#29 0x00007f34ed25b0ad in QEventLoop::processEvents (this=0x7fff2719df10, flags=...) at kernel/qeventloop.cpp:149
#30 0x00007f34ed25b240 in QEventLoop::exec (this=0x7fff2719df10, flags=...) at kernel/qeventloop.cpp:204
#31 0x00007f34ed25e396 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1225
#32 0x00007f34ec0bd662 in QApplication::exec () at kernel/qapplication.cpp:3823
#33 0x00007f34eda16513 in Akonadi::ResourceBase::init (r=r@entry=0x7f34e0ea5d60) at /data/extra2/sources/kde-master/kde/kdepimlibs/akonadi/resourcebase.cpp:579
#34 0x0000000000419abe in Akonadi::ResourceBase::init<ImapResource> (argc=<optimized out>, argv=<optimized out>) at /data/extra2/installation/kde-masterd/include/akonadi/resourcebase.h:193
#35 0x00007f34e8908040 in __libc_start_main () from /usr/lib/libc.so.6
#36 0x000000000041992b in _start ()

I discovered one of the possible causes of the crash:

In ItemSync, when the ItemCreateJob fails, the TransactionSequence is rolled back and ItemSync emits finished() - to which ResourceBase reacts by marking the task as done and scheduling another task. However the BatchFetcher in IMAP resource is not aware of this and keeps feeding more items through ResourceBase::itemsRetrieved() - which eventually hits the assert in ResourceBase, because ResourceBase has already moved on to another non-sync task.

Not sure how to solve this - ItemSync is internal to ResourceBase, so there's no way how to tell resource implementation that ItemSync has failed and so that they should stop sending more items. Good-enough fix would probably be to make TransactionSequence in ItemSync to ignore ItemCreateJob failures and handle the error manually (somehow) and continue, or just abort, but let the caller to feed ItemSync all its items (just do nothing with them) and then terminate - i.e. prevent ItemSync for ever aborting prematurely. Proper fix would be to make Sync a cancellable operation, so that we can tell resource to stop feeding ResourceBase with items because there was an error.


Regarding the reasons for ItemCreateJob failure: in my case this was happening because somehow I had two items with the same RID in one Collection (probably the RID wasn't reset during MOVE or something), so MERGE handler will abort with "Multiple merge candidates" error and so the ItemCreateJob fails.

(In reply to Daniel Vrátil from comment #5)
> I discovered one of the possible causes of the crash:
> 
> In ItemSync, when the ItemCreateJob fails, the TransactionSequence is rolled
> back and ItemSync emits finished() - to which ResourceBase reacts by marking
> the task as done and scheduling another task. However the BatchFetcher in
> IMAP resource is not aware of this and keeps feeding more items through
> ResourceBase::itemsRetrieved() - which eventually hits the assert in
> ResourceBase, because ResourceBase has already moved on to another non-sync
> task.
> 

Interesting, I actually checked this codepath and though it's fine.
ItemSync::slotResult is supposed to handle this case by silently ignoring errors and continuing anyways. I take that somehow doesn't work then?

> Not sure how to solve this - ItemSync is internal to ResourceBase, so
> there's no way how to tell resource implementation that ItemSync has failed
> and so that they should stop sending more items. 

Just as we can ask for more items, we should also be able to signal that the task was aborted.
But it's in any case a mess to pass this through the current API, so I'd prefer to postpone that for a new API.

>Good-enough fix would
> probably be to make TransactionSequence in ItemSync to ignore ItemCreateJob
> failures and handle the error manually (somehow) and continue, or just
> abort, but let the caller to feed ItemSync all its items (just do nothing
> with them) and then terminate - i.e. prevent ItemSync for ever aborting
> prematurely. Proper fix would be to make Sync a cancellable operation, so
> that we can tell resource to stop feeding ResourceBase with items because
> there was an error.
> 

I'm for simply continuing with the sync.

> 
> Regarding the reasons for ItemCreateJob failure: in my case this was
> happening because somehow I had two items with the same RID in one
> Collection (probably the RID wasn't reset during MOVE or something), so
> MERGE handler will abort with "Multiple merge candidates" error and so the
> ItemCreateJob fails.

Something to investigate.

*** This bug has been marked as a duplicate of bug 338658 ***