https://bugs.kde.org/show_bug.cgi?id=427378
Igor Kushnir changed:
What|Removed |Added
Latest Commit||https://invent.kde.org/kdev
||elop/kdevelop/commit/3f1b63
||92cb528d7b8986ab9a0a641cd9e
||346ef8d
Status|ASSIGNED|RESOLVED
Resolution|--- |FIXED
Version Fixed In||5.7.0
--- Comment #1 from Igor Kushnir ---
Git commit 3f1b6392cb528d7b8986ab9a0a641cd9e346ef8d by Igor Kushnir.
Committed on 13/02/2021 at 08:36.
Pushed by igorkushnir into branch 'master'.
Don't process events in ProjectFileDataProvider::projectOpened()
When a user exits KDevelop or closes the just opened project in the
ProjectFileDataProvider::projectOpened()'s nested event loop,
IProjectController::projectClosing() signal is emitted before some slots
connected to IProjectController::projectOpened() signal ale invoked
(more precisely, the slots that were connected to projectOpened() signal
later than the ProjectFileDataProvider::projectOpened() slot). Thus a
valid assumption that a slot connected to projectOpened() is always
called before a slot connected to projectClosing() becomes incorrect and
causes a crash, e.g. a segmentation fault in
ClassModel::removeProjectNode(). In addition,
ProjectController::projectImportingFinished() calls reparseProject()
after emitting the projectOpened() signal. Delaying this call until
after the project is closed and possibly destroyed would likely case a
crash or some other bug.
Queuing the slow code and its associated QApplication::processEvents()
instead of calling it directly in
ProjectFileDataProvider::projectOpened() would not eliminate the crash,
but move the segmentation fault from an unrelated class to
ProjectFileDataProvider::fileAddedToSet().
When the user disables the Quick Open plugin in this projectOpened()'s
nested event loop, a similar crash occurs.
These crashes could be fixed by checking whether the project is still
open and checking QPointer{this} after the call to
QApplication::processEvents(). But the code wouldn't become crash-proof
even then. ProjectFileDataProvider should not enter a nested event loop
while iterating over the project tree, because a project item can be
destroyed during the event loop when a user removes a file, which can
make one of the pointers to ProjectBaseItem held by
KDevelop::forEachFile() dangling.
The benefits of eliminating the nested event loop:
1) no need for verbose crash workarounds;
2) opening projects can be optimized by sorting and merging sorted
ranges. In particular, a performance pitfall, when multiple large
projects are opened in a certain order, can be eliminated.
Related: bug 427379
FIXED-IN: 5.7.0
M +0-8plugins/quickopen/projectfilequickopen.cpp
https://invent.kde.org/kdevelop/kdevelop/commit/3f1b6392cb528d7b8986ab9a0a641cd9e346ef8d
--
You are receiving this mail because:
You are watching all bug changes.
