https://bugs.kde.org/show_bug.cgi?id=306128
--- Comment #5 from RJVB <rjvber...@gmail.com> ---
Let me copy part of the duplicate I just filed (through DrKonqi which didn't
find this report):
In a debug build the ASSERTS will provoke an abort in the situation that caused
my latest hang, but now that KDevelop5 has seen 2 release versions already
anomalies in deleteItem() should also be handled (as elegantly as possible) in
release builds.
Apparently currentIndex should never become 0. What would be the side-effects
of returning early from deleteItem(), i.e.
//If this assertion triggers, the deleted item was not registered under
the given hash
Q_ASSERT(currentIndex);
+ if (!currentIndex) {
+ return;
+ }
It seems deleteItem() has no business trying to delete an item that's not
registered under the current hash, but not doing anything may mean we'll end up
in slightly larger closed loop, calling deleteItem() on the same item
indefinitely?
--
You are receiving this mail because:
You are watching all bug changes.
