Created attachment 164934 [details]
Fixed file

I'm not managing to reproduce this, I'm afraid. I've enabled the animation workspace and the storyboard docker, loaded the file, created a new one and clicked on the tab for the test_freeze file. There's no unexpected cpu usage and everything is responsive.

Created attachment 164981 [details]
Video of what happen when it freeze

You may have to retry :) 

On my side, 9 times on 10, it freeze immediately when i try to switch back to new document, but sometimes, you need to made more switches before being freezed

Here's a video "krita_freeze.webm" to show the case
Also you can see when it freeze, there's a lot of threads running, but CPU consumption is 0%
(all visible threads are not running when not in freeze)

Any tip about what I can to to get some logs when this occurs?
Eventually, I've installed Dmitri's build-docker so I can build a krita with some extra logs informations if needed

Grum999

I can confirm the freeze with 0% CPU after doing three switches between test_freeze.kra and a new document.
This was with the 5.2.2 appimage and the 17th Jan 5.3.0 pre-alpha (git c237d74b57) on Linux Mint 21.3.
The cursor moves but there is no canvas painting or UI response.

At first, I wanted to write that I can confirm this error. Now I have to write that I can partially (or halfway) confirm it. Tested on Windows 10 with two different installations of Krita 5.2.2.
For all the following tests, I created a blank file in DIN A6 portrait format, 300DPI. 

Since yesterday, I ran several tests, the first with my standard installation that has been running for days, which is "stuffed" with tons of plugins, bundles, brushes, gradients, i.e. resources en masse, the "resourcecache.sqlite" is almost 14 GB in size. 
I used it to open "test_freeze.kra", then created a new document, and was able to switch back and forth between the two documents at will. After about ten times back and forth, I scribbled something on the new document, and I started the animation and let it run, and then I could continue to switch back and forth at will. 
Then I went back to bugs.kde.org to check the task to see if I was doing everything right, and when I switched back to Krita, Krita froze without generating any processor load. Okay, even if I didn't expect it then, I should have expected it. 
I terminated Krita via the task manager. 

Next test with a fresh minimally customized version 5.2.2 on a different user account, with few plugins and hardly any extra resources, apart from ~700 MB ASL files (layerstyles) that I had forgotten, and a "resourcecache.sqlite" of about 380 MB. 
With the installation I can still work without freeze after umpteen switches between documents, then playing the "animation", then doodling on the new document, switching to any currently open application. I have now closed the files and ended this installation. 

Next test yesterday evening, again with the "maximum installation" used in the first test. 
After I started my standard installation again, I first loaded the file "test_freeze.kra" according to the bug report and then created a new empty project. After countless switches between documents, playing the animation, doodling on the new document, then switching between different applications, I can still use Krita without freezing. Since I had something else to do, I canceled after several switches. 
Shortly afterward, I fell asleep and had forgotten/forgotten about the tests until I read your post. 

That's why I tested it just again, and again I was able to switch back and forth infinitely, paint on the empty document after a few changes, start the animation, but after switching to the browser and back, Krita got stuck again, but only shortly for ~20 seconds, since then it is running. Huh?

If you find this can be called confirmed, then I ask you to set it to confirmed, in my eyes, this is very unclear / hard to grasp.

Michelist // Michael Strothotte

Yes, with all of that, it can be confirmet. But what's going...

Remove triaged keyword from CONFIRMED bugs

Yeah. I've been able to reproduce this on the master branch.
To confirm what was said above, the lock seems to happen as a response to clicking on the other document tab while this animation file is open.

Seems likely to be a thread locking / data race issue, so I'm not sure how useful this'll be, but I have a backtrace:

```
#0  futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x7ffccc009510) at ../sysdeps/nptl/futex-internal.h:183
#1  __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x7ffccc0094c0, cond=0x7ffccc0094e8) at pthread_cond_wait.c:508
#2  __pthread_cond_wait (cond=0x7ffccc0094e8, mutex=0x7ffccc0094c0) at pthread_cond_wait.c:647
#3  0x00007ffff50d52eb in QWaitCondition::wait(QMutex*, QDeadlineTimer) () from /home/appimage/appimage-workspace/deps/usr/lib/libQt5Core.so.5
#4  0x00007ffff6c95061 in KisUpdaterContext::waitForDone (this=0x7fff7400e330) at /home/appimage/persistent/krita/libs/image/kis_updater_context.cpp:213
#5  0x00007ffff6cac145 in KisUpdateScheduler::waitForDone (this=0x55555bb81698) at /home/appimage/persistent/krita/libs/image/kis_update_scheduler.cpp:365
#6  0x00007ffff6cce1bd in KisImage::waitForDone (this=0x7ffcd8004030) at /home/appimage/persistent/krita/libs/image/kis_image.cc:1865
#7  0x00007ffff6cdcd18 in KisImage::~KisImage (this=0x7ffcd8004030, __in_chrg=<optimized out>) at /home/appimage/persistent/krita/libs/image/kis_image.cc:331
#8  0x00007ffff6cdcdfd in KisImage::~KisImage (this=0x7ffcd8004030, __in_chrg=<optimized out>) at /home/appimage/persistent/krita/libs/image/kis_image.cc:335
#9  0x00007ffff7c86466 in KisSharedPtr<KisImage>::deref (sp=<optimized out>, t=<optimized out>) at /home/appimage/persistent/krita/libs/global/kis_shared_ptr.h:202
#10 KisSharedPtr<KisImage>::deref (t=<optimized out>, sp=<optimized out>) at /home/appimage/persistent/krita/libs/global/kis_shared_ptr.h:194
#11 KisSharedPtr<KisImage>::attach (p=0x0, this=<optimized out>) at /home/appimage/persistent/krita/libs/global/kis_shared_ptr.h:509
#12 KisSharedPtr<KisImage>::operator= (p=0x0, this=<optimized out>) at /home/appimage/persistent/krita/libs/global/kis_shared_ptr.h:121
#13 KisAsyncAnimationRendererBase::clearFrameRegenerationState (this=0x5555584a6bc0, isCancelled=<optimized out>)
    at /home/appimage/persistent/krita/libs/ui/KisAsyncAnimationRendererBase.cpp:172
#14 0x00007ffff7c8613a in operator() (__closure=<synthetic pointer>) at /home/appimage/persistent/krita/libs/ui/KisAsyncAnimationRendererBase.cpp:155
#15 kismpl::finally<KisAsyncAnimationRendererBase::notifyFrameCancelled(int, KisAsyncAnimationRendererBase::CancelReason)::<lambda()> >::~finally (
    this=<synthetic pointer>, __in_chrg=<optimized out>) at /home/appimage/persistent/krita/libs/global/KisMpl.h:428
#16 KisAsyncAnimationRendererBase::notifyFrameCancelled (this=0x5555584a6bc0, frame=279, cancelReason=KisAsyncAnimationRendererBase::UserCancelled)
    at /home/appimage/persistent/krita/libs/ui/KisAsyncAnimationRendererBase.cpp:160
#17 0x00007ffff52f89de in QObject::event(QEvent*) () from /home/appimage/appimage-workspace/deps/usr/lib/libQt5Core.so.5
#18 0x00007ffff5f6e7e3 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /home/appimage/appimage-workspace/deps/usr/lib/libQt5Widgets.so.5
#19 0x00007ffff7b7be35 in KisApplication::notify (this=0x7fffffffe030, receiver=0x5555584a6bc0, event=0x55555cf026f0)
    at /home/appimage/persistent/krita/libs/ui/KisApplication.cpp:774
#20 0x00007ffff52caf4a in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /home/appimage/appimage-workspace/deps/usr/lib/libQt5Core.so.5
#21 0x00007ffff52ce047 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) ()
   from /home/appimage/appimage-workspace/deps/usr/lib/libQt5Core.so.5
#22 0x00007ffff5325407 in ?? () from /home/appimage/appimage-workspace/deps/usr/lib/libQt5Core.so.5
#23 0x00007ffff294217d in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#24 0x00007ffff2942400 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#25 0x00007ffff29424a3 in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#26 0x00007ffff5324a58 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
   from /home/appimage/appimage-workspace/deps/usr/lib/libQt5Core.so.5
#27 0x00007ffff52c985b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /home/appimage/appimage-workspace/deps/usr/lib/libQt5Core.so.5
#28 0x00007ffff52d1e14 in QCoreApplication::exec() () from /home/appimage/appimage-workspace/deps/usr/lib/libQt5Core.so.5
#29 0x000055555555e02c in main (argc=<optimized out>, argv=<optimized out>) at /home/appimage/persistent/krita/krita/main.cc:790
```

I spent quite a bit of time investigating this today and it seems to be a problem with the generation of Storyboard Docker thumbnail images when a Transform Mask is active.

I don't have a fix just yet... but basically my understanding of the problem is this:if we switch to a different document while the Storyboard Docker is updating its thumbnails Krita tries to cancel the regeneration (via`KisAsyncAnimationRendererBase::clearFrameRegenerationState`). This seems to cause KisImage to get stuck in an infinite waiting loops as we wait for `KisUpdaterContext::waitForDone` to finish (but, for some reason I don't know yet, it never does). 

Workaround #1 (deleting the storyboard content form the KRA file) prevents the issue because there is no longer any need to do/cancel the storyboard docker thumbnail image regeneration. 

Workaround #2 is still a mystery to me right now because I don't understand how the Transformation Masks are factoring into the problem, although it definitely is, because hiding the Transformation Mask also prevents the problem from happening.

More investigation is needed, but I'm getting closer.

This sounds a lot like https://bugs.kde.org/show_bug.cgi?id=492011 ?

(In reply to Halla Rempt from comment #10)
> This sounds a lot like https://bugs.kde.org/show_bug.cgi?id=492011 ?

It could be, but I'm not so sure yet. I spent some time looking into that one today just in case it gave me a lead on this one, but I wasn't able to reproduce that one or get a backtrace. The file in question there may just be a bit too ambitious in its use of Transform Masks for animating every limb.

This big difference with this bug is that this one seems to be cause by some interaction between the Storyboard Docker and Transform Masks. If we get rid of the storyboard docker content Krita no longer freezes. Similarly, if we hide the Transform Masks it doesn't freeze either. It's a bit tricky...

*** Bug 486396 has been marked as a duplicate of this bug. ***