[Akonadi] [Bug 328601] New: Callbacks to ResourceTasks with an invalid state can lead to crashes

[Christian Mollekopf]

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

            Bug ID: 328601
           Summary: Callbacks to ResourceTasks with an invalid state can
                    lead to crashes
    Classification: Unclassified
           Product: Akonadi
           Version: GIT (master)
          Platform: unspecified
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: NOR
         Component: IMAP resource
          Assignee: chrigi_1 at fastmail.fm
          Reporter: mollekopf at kolabsys.com
                CC: kdepim-bugs at kde.org, vkrause at kde.org

Currently ResourceTasks are prone to crashes because it can quite easily happen
that a ResourceTask receives a callback, after the state of the ResourceTask
already became invalid.
Typical situations are:
* the resource is shutdown
* the resource goes offline/online
* the server goes offline/online

All these situations can lead to i.e. the SessionPool reconnecting resulting in
all sessions becoming invalid. ResourceTasks can then return to a state where
they:
* access an invalid session
* other assumptions about the resource are no longer true
* the task is already canceled

This bugreport is used to collect the various related crashreports (although
the backtraces can vary, since this can happen pretty much to every
ResourceTask).

As countermeasures:

* tasks should be always killed first, in order to avoid them getting signaled
by the dropped session resulting form the sessionpool disconnect.
* always delete the tasks immediately, otherwise callbacks can occur to tasks
that are already killed and have an invalid state.
* always stop the idlemanager first, and only delete it if it is also available

One particular case that I observed, was a RetrieveItemTask during which the
SessionPool was disconnected while the KIMAP::ItemFetchJob was running,
resulting in the RetrieveItemTask trying to deliver an item while it was
already canceled.
This triggered: ASSERT: "d->scheduler->currentTask().type ==
ResourceScheduler::FetchItem"
Of course we're dealing with the more general case that a ResourceTask must not
be called again,
once it's state becomes invalid.


Reproducible: Always

-- 
You are receiving this mail because:
You are on the CC list for the bug.