https://bugs.kde.org/show_bug.cgi?id=363279
Friedrich W. H. Kossebau <kosse...@kde.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|Crash on autosave? |Crash on autosave (assert
| |triggered for unbalanced
| |unlock)
Assignee|krita-bugs-n...@kde.org |dimul...@gmail.com
--- Comment #1 from Friedrich W. H. Kossebau <kosse...@kde.org> ---
Seems I am the only one running Krita as "debug" build since May 6th, to hit
asserts? :)
Not sure given I have no real experience with lock systems. The crash I hit was
due to Q_ASSERT(locked()); in KisImage::unlock(). The reason is that
KisDocument::Private::SafeSavingLocker uses a member KisImageBarrierLockAdapter
m_imageLock. Which it explicitely unlocks again, to keep locking in balance,
together with std::try_lock. Just, KisImageBarrierLockAdapter in its
deconstructor unconditionally calls unlock on the image, not taking into
account any state of other unlock/lock calls. Which seems strange to me (but
perhaps that is some pattern in lock code writing?). At least the assert in
KisImage::unlock() is expecting else.
As Lockable/BasicLockable seem to not require that unlock in the destructor,
and the only current usecase of KisImageBarrierLockAdapterImpl explicitely
cares for unlocking, this patch here makes the assert happy at least, by no
longer doing unbalanced unlock calls:
diff --git a/libs/image/kis_image_barrier_lock_adapter.h
b/libs/image/kis_image_barrier_lock_adapter.h
index 2f949e2..734381a 100644
--- a/libs/image/kis_image_barrier_lock_adapter.h
+++ b/libs/image/kis_image_barrier_lock_adapter.h
@@ -30,7 +30,6 @@ public:
}
inline ~KisImageBarrierLockAdapterImpl() {
- m_image->unlock();
}
inline void lock() {
lines 1-12/12 (END)
--
You are receiving this mail because:
You are watching all bug changes.
