1. 26 Feb, 2020 1 commit
  2. 16 Jan, 2020 1 commit
  3. 06 Jan, 2020 1 commit
  4. 04 Jan, 2020 2 commits
  5. 02 Jan, 2020 2 commits
  6. 09 Dec, 2019 1 commit
  7. 19 Jun, 2019 1 commit
  8. 31 May, 2019 1 commit
    • Daniel Vrátil's avatar
      Fix a crash due to weird refcount messup during stack unwinding · 7f104d75
      Daniel Vrátil authored
      Summary:
      My Akonadi Server has been crashing repeatadly whenever an exception was
      thrown inside a handler. The crash was due to memory corruption when
      stack unwinding caused the refcount of the "cmd" shared pointer to get
      messed up which lead to double-free corruption.
      
      The problem seems to be in the capture-by-value of the shared pointer in the
      lambda, but I do not exactly understand what causes the problem, neither
      was I able to produce a minimal reproducer case.
      
      We can safely capture the shared pointer by reference, we don't keep a
      reference to the functor anywhere.
      
      Reviewers: #kde_pim, vkrause
      
      Reviewed By: #kde_pim, vkrause
      
      Subscribers: kde-pim
      
      Tags: #kde_pim
      
      Differential Revision: https://phabricator.kde.org/D21456
      7f104d75
  9. 13 May, 2019 1 commit
  10. 09 May, 2019 1 commit
  11. 03 May, 2019 1 commit
  12. 28 Apr, 2019 1 commit
  13. 15 Apr, 2019 1 commit
  14. 07 Apr, 2019 1 commit
    • David Faure's avatar
      Akonadiserver: rework handling of database deadlocks. · 5b5b9fad
      David Faure authored
      Summary:
      We can't just replay the SQL commands, that's too low-level: if we do
      INSERT, then use the resulting ID into e.g. another INSERT command, at replay
      time we might get a different ID from the first command, and then insert
      the wrong ID in the second one...
      
      So instead we want to re-run the entire handler's parseStream(), which we
      do by throwing a DbDeadlockException (from QueryBuilder), and catching that
      in the caller (Connection) using a helper class (DbDeadlockCatcher, unittested)
      which retries up to 5 times.
      
      For this to work, it means:
      - we must also rollback any chances made to in-memory caches (done by
      clearing those caches, good enough since DB deadlocks are rare)
      - ItemModifyJob which sends parts on demand, shouldn't delete after
      sending (it might be asked again) -- this was hit by GidTest (fetchAndSetGid).
      
      Still TODO:
      - delaying the updating of intervalChecker and cacheCleaner by NotificationCollector
          until commit time;
      - checking other users of QueryBuilder (who now can get a DbDeadlockException...)
      
      Test Plan:
      all this was triggered by a unittest that creates 10 sessions
      and adds 10 different attributes to the same time, one in each session. This very
      often hits the DB deadlock scenario.
      
      Reviewers: dvratil, vkrause
      
      Reviewed By: dvratil
      
      Subscribers: kde-pim
      
      Tags: #kde_pim
      
      Differential Revision: https://phabricator.kde.org/D20326
      5b5b9fad
  15. 26 Feb, 2019 1 commit
  16. 01 Dec, 2018 1 commit
  17. 27 Aug, 2018 2 commits
  18. 15 Jul, 2018 1 commit
  19. 14 Jul, 2018 3 commits
  20. 05 Jul, 2018 1 commit
    • Daniel Vrátil's avatar
      Server: handle race condition on connection shutdown · 154cfb8f
      Daniel Vrátil authored
      When client sends a command and disconnects immediatelly it is possible
      that the Connection gets mostly torn down from a nested event loop
      before we get back to the main loop in handleIncomingData(),
      leading to m_socket being null when we try to access it.
      
      BUG: 394071
      FIXED-IN: 5.8.3
      154cfb8f
  21. 21 Jun, 2018 1 commit
  22. 21 Apr, 2018 1 commit
  23. 19 Jan, 2018 1 commit
    • Daniel Vrátil's avatar
      Use QIODevice::readyRead() to wait for incoming data · 2058ae6c
      Daniel Vrátil authored
      Also avoid any reading code to be executed in a slot connected to
      readyRead() signal because Qt will not emit readyRead() signal
      recursively. This change is needed to make Akonadi work on Windows,
      because the blocking QLocalSocket::waitForReadyRead() does not work
      reliably there.
      
      On Linux QLocalSocket::waitForReadyRead() is used internally only
      in DataStream for performance reasons. On Windows DataStream will
      internally instantiate a QEventLoop and wait for the readyRead()
      signal, which is more expensive, especially since DataStream can
      get into the wait state multiple times while reading a single
      command.
      2058ae6c
  24. 23 Dec, 2017 1 commit
  25. 30 May, 2017 1 commit
  26. 20 May, 2017 1 commit
  27. 23 Apr, 2017 2 commits
    • Daniel Vrátil's avatar
      Generate Protocol from an XML specification (ABI break) · 5535d6e5
      Daniel Vrátil authored
      Instead of maintaining 12k lines of hand-written protocol code, we
      specify the protocol in an XML and use a custom-written generator
      that generates the code for us.
      
      It's not only much easier to modify the protocol - we only need to
      change a single thing in the XML instead of touching several places
      of the implementation - but it's also much safer, as there's less
      risk of accidentally introducing a bug in the code.
      
      The major difference between the original hand-written code and the
      generated code is that we no longer use QSharedDataPointer and virtual
      methods in the Private classes, but instead all members are directly
      in the command clas with most getters and setters inlined. This means
      that copying commands is quite costly, so we pass them around as
      QSharedPointers or const references. This should give us a tiny little
      bit more performance.
      5535d6e5
    • Daniel Vrátil's avatar
      Prevent sending multiple error messages from a single Handler · 47113076
      Daniel Vrátil authored
      Prevent single Handler from issuing multiple failureResponse()s, or
      the Handler emitting one and then Connection sending another. The
      client Jobs only expect a single error response, so when they get
      more than one, it messses up result handling especially with nested
       jobs (like Transactions or ItemSync)
      47113076
  28. 01 Apr, 2017 1 commit
  29. 26 Mar, 2017 1 commit
    • Tobias C. Berner's avatar
      abi::__forced_unwind is only part of gnu's libstc++. · 9414ca9c
      Tobias C. Berner authored
      Summary:
      /wrkdirs/usr/ports/databases/akonadi/work/akonadi-17.03.80/src/server/connection.cpp:270:23: error: no type named '__forced_unwind' in namespace '__cxxabiv1'
              } catch (abi::__forced_unwind&) {
                       ~~~~~^
      1 error generated.
      
      NPTL is Linux's posix thread implementation, so that exception thrown by it, should only affect the Linux platforms.
      
      Subscribers: #kde_pim
      
      Tags: #kde_pim
      
      Differential Revision: https://phabricator.kde.org/D5168
      9414ca9c
  30. 25 Mar, 2017 1 commit
  31. 24 Feb, 2017 1 commit
    • Daniel Vrátil's avatar
      Fix crash when Connection is closed while ItemRetriever is running · 1593c17d
      Daniel Vrátil authored
      ItemRetriever::exec() runs a nested QEventLoop. If the parent
      Connection is terminated while the event loop is running, the
      delayed AkThread::quit() invocation is executed and the thread
      is destroyed, while technically there is still execution going
      on. To workaround that issue we don't destroy the thread in
      Connection::quit() if we detect a nested QEventLoop but instead
      we just notify the event loop to quit and destroy the thread
      later when execution returns back to ItemRetriever::slotNewData().
      
      This fixes a crash in QPSQLQuery, which was dereferencing a
      QPSQLDriver after the driver has been deleted as the thread was
      destroyed and avoids more of random crashes due to the Connection
      being virtually deleted from its own nested event loop.
      
      BUG: 374734
      FIXED-IN: 5.4.3
      1593c17d
  32. 14 Feb, 2017 1 commit
    • David Faure's avatar
      Setting a thread's object name after calling start() is a data race. · 1ccd5f40
      David Faure authored
      QThreadPrivate::start() uses the thread's objectName() to set the thread
      name in pthread (PR_SET_NAME), so we must provide it before calling start.
      Given that AkThread calls start in the constructor, this means passing
      the string as a constructor argument.
      
      While at it, simplify code by using that string for both the object name
      of the AkThread (QObject) and the object name of its QThread.
      
      Detected by clang's thread-sanitizer.
      
      CCMAIL: dvratil@kde.org
      1ccd5f40
  33. 15 Jan, 2017 1 commit
  34. 13 Jan, 2017 1 commit