Created attachment 130004 [details] Crash log & backtraces obtained with GDB SUMMARY Selecting a range of frames in the timeline docker, for a "long" animation that has frames outside the visible range, causes Krita to crash on one machine and triggers a SAFE ASSERT on another. STEPS TO REPRODUCE 1. Open a file with an animation that's long enough to not fit in the timeline docker (I can provide the crashing file if necessary, but it's pretty big) 2. Scroll the timeline docker to the right to see animation frames that were hidden on startup 3. Try to select some frames by dragging the pointer while the mouse button is pressed OBSERVED RESULT An assert failure EXPECTED RESULT Some frames are selected in the timeline docker SOFTWARE/OS VERSIONS Linux/KDE Plasma: Debian Testing / Linux 5.7.0-1-amd64 / KDE Plasma 5.17.5 KDE Frameworks Version: 5.70.0 Qt Version: 5.14.2 ADDITIONAL INFORMATION Built from git 3be762c On a machine, it doesn't crash but shows a "SAFE ASSERT (krita): "animInterface->fullClipRange().contains(frame)" in file /home/etienne/kritadev/krita/libs/ui/KisPart.cpp, line 488" On another machine, it simply crashes. I've reproduced the issue with gdb, the log is attached.
I added 'regression' keyword because it seems like there is quite some amount of crashes for animation in the current version which weren't in, let's say, 4.2.6, and they need attention. It would be good if someone checked and confirmed if this assert/crash happens in 4.2.9 too or not.
I can confirm it's a regression at least from my point of view. The same animation file which makes 4.3 onwards crash was created and is editable in 4.2.9.
I can confirm this for the 4.3.0 appimage on Debian Stable with various existing animation files. The animation plays ok but then crashes if I try to select a frame or try to scrub along the timeline. Example terminal output: QPainter::begin: Paint device returned engine == 0, type: 3 QPainter::setCompositionMode: Painter not active QPainter::begin: Paint device returned engine == 0, type: 3 QPainter::setCompositionMode: Painter not active QPainter::begin: Paint device returned engine == 0, type: 3 QPainter::setCompositionMode: Painter not active Segmentation fault
For Comment 3, I had a fresh kritarc file but not a fresh kritadisplayrc file. As a result of this, I had Canvas Graphics Acceleration disabled. Crash induction for 4.3.0 onwards appimages is as follows: 1. Disable Canvas Graphics Acceleration 2. Create a new image and have the Timeline showing. 3. Click-hold anywhere in the timeline and move the cursor slightly. 4. See a crash. This may (or may not) be the same cause for the crash by etene. This may (or may not) be associated with: https://bugs.kde.org/show_bug.cgi?id=423840 though this bug is caused by changing the state of Canvas Graphics Acceleration.
Created attachment 130051 [details] Win10 krita-5.0.0 crash log It's the same for appimages on Ubuntu 20.04 and for the latest Nightly 5.0.0 portable zip package on Windows 10 The Windows 10 crash log is attached
I can confirm that the machine on which it crashes had canvas graphic acceleration disabled. Enabling it stops it from crashing mid flight (but it crashes on exit instead).
If Canvas Graphics Acceleration is enabled to start with, I don't see a crash on exit or significant output in the terminal. If it's disabled to start with, setting it to enabled will lock up the canvas (as noted in Comment 4 ) but I see no significant output in the terminal after exit.
Git commit 82c952ffbbb295720bc903ec8ab683d13a6bcddb by Eoin O'Neill. Committed on 13/07/2020 at 18:02. Pushed by eoinoneill into branch 'krita/4.3'. Fix Crash on Frame Priority Caching when Graphics Acceleration is Disabled. Additional measures had to be taken to ensure that the frame cache exists before requesting frame regeneration. Additionally, frame cache priority will also ensure that the user wants background caching before attempting to prioritize specific frames. M +5 -1 libs/ui/kis_animation_cache_populator.cpp M +7 -4 plugins/dockers/animation/kis_time_based_item_model.cpp https://invent.kde.org/graphics/krita/commit/82c952ffbbb295720bc903ec8ab683d13a6bcddb
Git commit 6182b39b71a66aa67a2caa523ebdf29597aaf813 by Eoin O'Neill. Committed on 13/07/2020 at 18:25. Pushed by eoinoneill into branch 'krita/4.3.0'. Fix Crash on Frame Priority Caching when Graphics Acceleration is Disabled. Additional measures had to be taken to ensure that the frame cache exists before requesting frame regeneration. Additionally, frame cache priority will also ensure that the user wants background caching before attempting to prioritize specific frames. (cherry picked from commit 82c952ffbbb295720bc903ec8ab683d13a6bcddb) M +5 -1 libs/ui/kis_animation_cache_populator.cpp M +7 -4 plugins/dockers/animation/kis_time_based_item_model.cpp https://invent.kde.org/graphics/krita/commit/6182b39b71a66aa67a2caa523ebdf29597aaf813
Git commit 844b976d30f54531ee02a41d9b1c9bb0fcafbc2d by Eoin O'Neill. Committed on 13/07/2020 at 20:03. Pushed by eoinoneill into branch 'master'. Fix Crash on Frame Priority Caching when Graphics Acceleration is Disabled. Additional measures had to be taken to ensure that the frame cache exists before requesting frame regeneration. Additionally, frame cache priority will also ensure that the user wants background caching before attempting to prioritize specific frames. (cherry picked from krita/4.3 commit 82c952ffbbb295720bc903ec8ab683d13a6bcddb) M +5 -1 libs/ui/kis_animation_cache_populator.cpp M +7 -4 plugins/dockers/animation/kis_time_based_item_model.cpp https://invent.kde.org/graphics/krita/commit/844b976d30f54531ee02a41d9b1c9bb0fcafbc2d
*** Bug 424220 has been marked as a duplicate of this bug. ***
*** Bug 425199 has been marked as a duplicate of this bug. ***