Created attachment 149050 [details] bug The log file has been uploaded as an attachment. I withdrew a large number of operations (no more than 200) at one time in "undo history". It includes importing pictures, GMIC filters, creating selection and applying filter masks. The system is win11 The hardware is 5800x + 6600xt + 32g ram
I haven't been able to reproduce this, but maybe the backtrace is enough to figure out what might be going on.
Hi, thetwo! Could you please check if your krita.log has any lines with asserts during that Krita session on Saturday, May 21, 2022 at 07:36:36? The lines should contain something like that: KIS_SAFE_ASSERT_RECOVER_RETURN(m_d->pendingNodeSet.contains(node))
My current krita.log file starts recording from 27, July. Maybe I lost it in the backups I tested many times…
Git commit 28f09577961ee21438c9d9f52744a59ecd1ff38d by Dmitry Kazakov. Committed on 09/08/2022 at 09:20. Pushed by dkazakov into branch 'master'. Fix a severe bug when undo actions could become incomplete Most of our undo actions are executed in strokes. It turned out that these strokes can easily be cancelled (like normal strokes are), leaving the image in inconsistent state. To achieve that the user should have been pressed Ctrl+Z too quickly (or switch undo state in the docker too quickly). The problem could manifest itself in several ways: 1) "Quick Group" action could be partially undone, leaving the group layer in the stack. 2) Which could cause several more severe outcomes, because on the next undo/redo the layer would be added into the stack once again, causing the following: * KisNode::add() would assert that the node is already in the stack * KisDummiesFacadeBase::slotContinueAddRemoveNode() would assert/crash on inconsistency between dummies and nodes (bug 454121) 3) Tile manager could catch this broken undo history by an assert in KisMementoManager::rollback() ``` KIS_SAFE_ASSERT_RECOVER_NOOP(changeList.memento == memento); ``` M +5 -0 libs/image/kis_stroke.cpp M +1 -0 libs/image/kis_stroke.h M +12 -0 libs/image/kis_stroke_strategy.cpp M +15 -0 libs/image/kis_stroke_strategy.h M +1 -0 libs/image/kis_stroke_strategy_undo_command_based.cpp M +16 -2 libs/image/kis_strokes_queue.cpp https://invent.kde.org/graphics/krita/commit/28f09577961ee21438c9d9f52744a59ecd1ff38d
Git commit 536cff4120bcdfd2be39e20549d78cbb4f2048e6 by Dmitry Kazakov. Committed on 09/08/2022 at 09:20. Pushed by dkazakov into branch 'master'. Fix an ordering of KisImage::sigRequestNodeReselection signal The signal should have exactly the same ordering as node addition/removal signals. Otherwise the node manager may observe some inconsistencies with the dummies graph. All node addition/removal signals are connected via a direct connection to a KisSynchronizedConnection object. So should the reselection signal. M +2 -1 libs/image/kis_image_signal_router.cpp https://invent.kde.org/graphics/krita/commit/536cff4120bcdfd2be39e20549d78cbb4f2048e6
Git commit b37df0b0e8f98e33659eef23b8e8a3759ce8c0a9 by Dmitry Kazakov. Committed on 09/08/2022 at 10:00. Pushed by dkazakov into branch 'krita/5.1'. Fix an ordering of KisImage::sigRequestNodeReselection signal The signal should have exactly the same ordering as node addition/removal signals. Otherwise the node manager may observe some inconsistencies with the dummies graph. All node addition/removal signals are connected via a direct connection to a KisSynchronizedConnection object. So should the reselection signal. M +2 -1 libs/image/kis_image_signal_router.cpp https://invent.kde.org/graphics/krita/commit/b37df0b0e8f98e33659eef23b8e8a3759ce8c0a9
Git commit 2d9c4c7204dccb8d03c0722a152756a6da1065cf by Dmitry Kazakov. Committed on 09/08/2022 at 10:00. Pushed by dkazakov into branch 'krita/5.1'. Fix a severe bug when undo actions could become incomplete Most of our undo actions are executed in strokes. It turned out that these strokes can easily be cancelled (like normal strokes are), leaving the image in inconsistent state. To achieve that the user should have been pressed Ctrl+Z too quickly (or switch undo state in the docker too quickly). The problem could manifest itself in several ways: 1) "Quick Group" action could be partially undone, leaving the group layer in the stack. 2) Which could cause several more severe outcomes, because on the next undo/redo the layer would be added into the stack once again, causing the following: * KisNode::add() would assert that the node is already in the stack * KisDummiesFacadeBase::slotContinueAddRemoveNode() would assert/crash on inconsistency between dummies and nodes (bug 454121) 3) Tile manager could catch this broken undo history by an assert in KisMementoManager::rollback() ``` KIS_SAFE_ASSERT_RECOVER_NOOP(changeList.memento == memento); ``` M +5 -0 libs/image/kis_stroke.cpp M +1 -0 libs/image/kis_stroke.h M +12 -0 libs/image/kis_stroke_strategy.cpp M +15 -0 libs/image/kis_stroke_strategy.h M +1 -0 libs/image/kis_stroke_strategy_undo_command_based.cpp M +16 -2 libs/image/kis_strokes_queue.cpp https://invent.kde.org/graphics/krita/commit/2d9c4c7204dccb8d03c0722a152756a6da1065cf