https://bugs.kde.org/show_bug.cgi?id=374734
Daniel Vrátil <dvra...@kde.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|critical |normal
CC| |dvra...@kde.org
Version Fixed In| |5.4.3
Latest Commit| |https://commits.kde.org/ako
| |nadi/5219f770b998aad16a3d51
| |bbd4f4c7ceb8b143c9
--- Comment #23 from Daniel Vrátil <dvra...@kde.org> ---
The crash itself has been fixed by commit
https://commits.kde.org/akonadi/5219f770b998aad16a3d51bbd4f4c7ceb8b143c9 which
will be in Akonadi 5.4.3 (KDE Applications 16.12.3) in March.
The patch fixes the crash itself, but does not address the underlying problem.
I'll keep this opened until the underlying problem is resolved.
--- Notes for future me:
The root cause is the nested QEventLoop in ItemRetriever::exec(). When
Connection is terminated (by server shutdown or connection loss on socket)
while the nested QEventLoop in ItemRetriever is running, Connection::quit()
will be invoked from the nested loop, destroying certain resources (socket,
datastore). This then leads to various crashes once the nested event loop ends
and execution within ItemRetriever::exec() continues.
I don't think it's possible to prevent nested event loop from executing
metacalls on Connection, after all the main reason for using QEventLoop in
ItemRetriever was to make it more interactive and interruptable.
Connection::quit() cannot directly terminate the nested QEventLoop, because it
has been invoked from it. It could however use delay invocation to quit the
loop and return early without actually quiting and destroying the thread. The
thread would quit once the excecution would return from the Handler back to
Connection::slotNewData(). Connection::quit() could probably set a flag or
something. However it's not clear how Connection::quit() should detect where
it's invoked from and whether it's a nested QEL or not, and how it should
interact with it.
--
You are receiving this mail because:
You are watching all bug changes.
