SUMMARY Regression introduced in 4.3.0: Krita throws safe asserts when the user creates a selection mask, copies the contents, then performs certain undo/redo actions. STEPS TO REPRODUCE 1. Draw something. 2. Freehand select it. 3. Copy it. 4. Undo twice. (the Copy action appears to be its own action in the undo stack) OBSERVED RESULT SAFE ASSERT (krita): "changeList.memento == memento" in file /home/appimage/workspace/Krita_Release_Appimage_Build/krita/libs/image/tiles3/kis_memento_manager.cc, line 285 When redoing after the above assert: SAFE ASSERT (krita): "changeList.memento == memento" in file /home/appimage/workspace/Krita_Release_Appimage_Build/krita/libs/image/tiles3/kis_memento_manager.cc, line 342 EXPECTED RESULT No asserts. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Debian sid KDE Plasma Version: 5.20.5 KDE Frameworks Version: 5.78.0 Qt Version: 5.12.9 (Appimage) ADDITIONAL INFORMATION Also occurs in master. Happens with both raster and vector selections.
I can confirm this for the Mar 30 5.0.0-prealpha (git 783e86c) appimage. The Copy action is needed. It doesnt happen if you do a brushstroke after the freehand (or any type of) selection.
Strange... I must be doing something wrong, since I cannot reproduce this.
If step 2 is skipped and you copy the whole layer, the Copy action isn't considered an item in the undo stack, and the safe assert doesn't happen at all when undoing twice.
Created attachment 138123 [details] Undo-Stack (Failed Attempt to Reproduce) I'm also unable to reproduce this bug. Since this is important for the upcoming release, could you please give us more information by providing a screenshot of the minimum undo stack that this occurs to you? Also, perhaps provide a canvas size and color space details. I've attached my undo stack to the attachments list. It seems like even the copy item being its own element in the undo stack isn't enough to have this guarantee to happen during undo/redo operations.
For the time being, I'm changing the status of this to NEEDSINFO > WORKSFORME. I will continue to track this as it is under my assignment.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!
Created attachment 140513 [details] Minimum necessary undo history to produce the safe assert
The above attachment is from Krita 4.4.5 with A5 600 DPI canvas size and default 8-bit color. The safe assert occurs when undoing to "Freehand Brush Stroke".
Tomtomtom, I'm still having issues reproducing this. I've tried it through the flatpak, appimage and master versions of krita with no success. I'm going to have to guess there's something external to Krita at work here.
I can't get the asserts with 4.4.5 or any version now. The only change from before, that I can think of, is that I do an update and distribution upgrade of my Debian 10 system every month.
The assert should have been fixed in a87dced5f88f26e282dfc86d18a3c32ecf68fa96 Though I cannot check if the patch is included into the reporter's version
The issue still happens for me in Krita 5. I've compared the behavior and configuration between my regular environment and a /tmp/ environment, and it seems to only happen with a Pixel selection nowadays.
Hi, Tomtomtom! Could you check if you still can reproduce the problem in the current Krita-Next? https://binary-factory.kde.org/job/Krita_Nightly_Windows_Build/ I cannot reproduce the problem, neither with pixel selections nor with vector selections :(
I can not reproduce the problem anymore, so I suppose it's been resolved in some way.