[Akonadi] [Bug 328421] New: Refactor session related codepaths to use jobs

Christian Mollekopf mollekopf at kolabsys.com
Wed Dec 4 11:29:55 GMT 2013


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

            Bug ID: 328421
           Summary: Refactor session related codepaths to use jobs
    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

The codepaths related to the session setup are currently very error prone,
since they use a lot of async code, but don't protect the internal state of the
objects sufficiently. This can be solved by moving all async code and the
related state to dedicated job objects.

In particular are synchronous dialogs invoked, meaning almost arbitrary
callbacks can occur if the user forgets a dialog and then closes it, at which
point the object may already be in a completely different state.

Some examples are:
* SessionPrivate::handleSslError invokes a dialog at the end of a process
started by SessionPrivate::startSsl, while the process depends on the internal
state of SessionThread and startSsl may be invoked multiple times. This means
SessoinThread::sslErrorHandlerResponse can be invoked at any time, even if a
second run of startSsl already succeeded and already established a secure
connection.

* SessionPool::onPasswordRequestDone can be invoked again due to a stale
password dialog getting completed. At this stage assumptions about the internal
state (such as m_pendingInitialSession being set in the ReconnectNeeded) are
likely to not be true anymore.

The bottom line is, either protect async codepaths from being entered multiple
times, or move the state to separate job objects, so the code can safely be run
multiple times in parallel.

I'm pretty sure this would fix at least some of the crashes we have in the imap
resource.

Reproducible: Always

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



More information about the Kdepim-bugs mailing list