Created attachment 160400 [details] Krita system information SUMMARY Drawing on any animation frame and then using the "Move a layer" tool (in a particular order) will crash when undone. Affects Krita 5.1.5 and Krita 5.2.0-prealpha (git bc41e49). STEPS TO REPRODUCE 1. Open or create any document with a paint layer. (A layer with existing frames is ok) 2. Draw anything on the paint layer. (A dot or line is ok) 3. Create new keyframe and draw 5. Go back to previous keyframe and draw 6. Use the "Move a layer" tool (T) to move the current drawing 7. Undo everything (Video demonstration attached) OBSERVED RESULT Krita abruptly crashes with the same access violation. (Full crash log attached) " Access Violation at location 00007FFDF2599EEB in module libkritaimage.dll Writing to location 0000000000000088 libkritaimage.dll!KisPaintDevice::Private::invalidateFrameCache+0x2b libkritaimage.dll!KisTransactionData::undo+0x1bf " EXPECTED RESULT All the "steps to reproduce" are undone. SOFTWARE/OS VERSIONS Windows: 10 (Version 21H2) Qt Version: 5.15.7 ADDITIONAL INFORMATION - This bug affects both Krita 5.1.5, Krita 5.2.0-prealpha (git bc41e49), - Video demonstration, crash log, and version info are attached
Created attachment 160401 [details] Crash log
Created attachment 160402 [details] Video demonstration of steps to reproduce
I cannot reproduce the bug on Linux. Perhaps it is something windows-specific...
(In reply to Dmitry Kazakov from comment #3) > I cannot reproduce the bug on Linux. Perhaps it is something > windows-specific... After reading this, I tried and successfully reproduced the bug on the following Linux VMs: - Ubuntu 20.04 VM with Krita 5.1.5 installed from snap - Linux Mint 21.2 VM with Krita 5.2.0-prealpha (git 449aeb5) AppImage downloaded from the website Here is a snippet of the gdb output after the AppImage crashed on Linux Mint: " Thread 19 "Thread (pooled)" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffdd3ed640 (LWP 2617)] 0x00007ffff71ee1c4 in ?? () from /tmp/.mount_krita-qNfEoX/usr/bin/../lib/libkritaimage.so.19 (gdb) bt #0 0x00007ffff71ee1c4 in ?? () from /tmp/.mount_krita-qNfEoX/usr/bin/../lib/libkritaimage.so.19 #1 0x00007ffff72249c5 in KisTransactionData::undo() () from /tmp/.mount_krita-qNfEoX/usr/bin/../lib/libkritaimage.so.19 #2 0x00007ffff45211d2 in KUndo2Command::undo() () from /tmp/.mount_krita-qNfEoX/usr/bin/../lib/libkritacommand.so.19 #3 0x00007ffff711e663 in KisStrokeStrategyUndoCommandBased::doStrokeCallback(KisStrokeJobData*) () from /tmp/.mount_krita-qNfEoX/usr/bin/../lib/libkritaimage.so.19 "
Just now I had another user confirm this with Krita 5.1.5 on Windows and Mac OS, in case it was only my machine.
Hi, Cade! Thank you for your info! I seem to be able to reproduce the issue now...
Git commit f692df5615344bb367895a784d28c96fa8cacb82 by Dmitry Kazakov. Committed on 23/08/2023 at 14:00. Pushed by dkazakov into branch 'master'. Don't recreate the frames when not necessary This bug was an artifact of the lazy-frames refactoring. The frames should not be recreated when they are actually the ones we transform. M +5 -2 libs/ui/tool/strokes/move_stroke_strategy.cpp https://invent.kde.org/graphics/krita/-/commit/f692df5615344bb367895a784d28c96fa8cacb82
Git commit e71e835fe66d1db8bd442db842d7892e1e19b204 by Dmitry Kazakov. Committed on 23/08/2023 at 14:03. Pushed by dkazakov into branch 'krita/5.2'. Don't recreate the frames when not necessary This bug was an artifact of the lazy-frames refactoring. The frames should not be recreated when they are actually the ones we transform. M +5 -2 libs/ui/tool/strokes/move_stroke_strategy.cpp https://invent.kde.org/graphics/krita/-/commit/e71e835fe66d1db8bd442db842d7892e1e19b204