Bug 424037

Summary: Animation: Crash when selecting a range of frames that's not visible on startup in the timeline docker
Product: [Applications] krita Reporter: etene <etienne.noss+kdebugs>
Component: AnimationAssignee: Eoin O'Neill <eoinoneill1991>
Status: RESOLVED FIXED    
Severity: crash CC: ahab.greybeard, azzyuya, eoinoneill1991, lauren16keogh, tamtamy.tymona
Priority: NOR Keywords: regression
Version: git master (please specify the git hash!)   
Target Milestone: ---   
Platform: Debian testing   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: Crash log & backtraces obtained with GDB
Win10 krita-5.0.0 crash log

Description etene 2020-07-09 19:59:11 UTC
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.
Comment 1 Tiar 2020-07-10 13:02:25 UTC
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.
Comment 2 etene 2020-07-10 13:44:17 UTC
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.
Comment 3 Ahab Greybeard 2020-07-11 06:29:10 UTC
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
Comment 4 Ahab Greybeard 2020-07-11 10:16:56 UTC
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.
Comment 5 Ahab Greybeard 2020-07-11 20:34:50 UTC
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
Comment 6 etene 2020-07-12 15:18:23 UTC
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).
Comment 7 Ahab Greybeard 2020-07-12 16:00:41 UTC
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.
Comment 8 Eoin O'Neill 2020-07-13 18:24:54 UTC
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
Comment 9 Eoin O'Neill 2020-07-13 19:21:10 UTC
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
Comment 10 Eoin O'Neill 2020-07-13 20:04:14 UTC
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
Comment 11 Eoin O'Neill 2020-07-17 04:44:24 UTC
*** Bug 424220 has been marked as a duplicate of this bug. ***
Comment 12 Eoin O'Neill 2020-08-15 22:21:05 UTC
*** Bug 425199 has been marked as a duplicate of this bug. ***