Bug 367901

I cannot reproduce it on my Linux system. I created a 3000x3000px image, 16 bit (int) RGB color. 5 layers and drew for a while, but the system is running fine.

Could you please provide more information:
1. What's the revision you are using? You can run git rev-parse HEAD to get it.
2. Which compiler (gcc or clang)?
3. What version of Qt are you using? 
4. What linux distro? 
5. Is it possible that you are running low on memory? Does "top" command show enough free memory and no swap is used. How much memory is krita using?
6. If you "dock" the overview docker, is krita still freezing?
7. If you close the overview docker, is it freezing?

Rev: 88a03cd3777a820db835f1e5eceb27346dd52d03

GCC:

COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.9.3/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.3/lto-wrapper
Ziel: x86_64-pc-linux-gnu
Konfiguriert mit: ../gcc-4.9.3/configure --disable-libssp --enable-multilib --enable-version-specific-runtime-libs --enable-libmudflap --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.9.3 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.3 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.3/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.3/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/g++-v4.9.3 --enable-libstdcxx-time --enable-__cxa_atexit --enable-clocale=gnu --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --with-system-zlib --enable-obsolete --disable-werror --enable-secureplt --enable-lto --without-cloog --with-bugurl=http://bugs.funtoo.org --with-pkgversion='Funtoo 4.9.3-r3' --with-mpfr-include=/var/tmp/portage/sys-devel/gcc-4.9.3-r3/work/gcc-4.9.3/mpfr/src --with-mpfr-lib=/var/tmp/portage/sys-devel/gcc-4.9.3-r3/work/objdir/mpfr/src/.libs --enable-libgomp --build=x86_64-pc-linux-gnu --enable-libgomp --enable-languages=c,c++,fortran --disable-libgcj --disable-esp --disable-libsanitizer
Thread-Modell: posix
gcc-Version 4.9.3 (Funtoo 4.9.3-r3)

QT: 5.6.1
Distro: Funtoo
Memory: Never checked it but when I run out of memory the systems cursor would get slow very bad. 8GB RAM here but I'll check that next time.

6. Not tested yet
7. Nope could draw with it closed for multiple hours

Created attachment 100814 [details]
My Krita ebuild

Freezes happen in docked mode too.

              total        used        free      shared  buff/cache   available
Mem:           7.7G        3.2G        253M        1.2G        4.3G        3.2G
Swap:          5.2G        316K        5.2G

Memory usage on krita looks good too: VIRT: 2843M RES: 985M SHR: 230M
I was using a liquify/move brush from Deevads 8.1 brush kit, but I doubt that is the root of the problem.
What I'm going to do now is using my nvidia card, maybe it's a bug with the intel module, which wouldn't surprise me.

Your configuration is similar to mine. I don't see how video driver could interact with overview widget.

Are you comfortable debugging krita? Could you try running krita in a debugger. Build with debug information and run 
"gdb krita"

When krita starts freezing, you can break in debugger and give "bt" command and then "c" to continue. Repeat a few times while krita is freezing. If you see that debugger often stops in the same places, could you post backtrace from bt command. It may point to the place where code is looping.

Your configuration is similar to mine. I don't see how video driver could interact with overview widget.

Are you comfortable debugging krita? Could you try running krita in a debugger. Build with debug information and run 
"gdb krita"

When krita starts freezing, you can break in debugger and give "bt" command and then "c" to continue. Repeat a few times while krita is freezing. If you see that debugger often stops in the same places, could you post backtrace from bt command. It may point to the place where code is looping.

Took me a while to got it to freeze, like a hour now I had 2 images open, one reference and my drawing image and of course the overview. I was doing quick brush strokes with a soft brush.

Going to attach the backtrace.

Created attachment 100853 [details]
GDB Backtrace right after the freeze

Oh boy. An hour of work and all we get is a single hit inside overviewwidget and no function name. :) :). However, it may be quite informative. Looking at stuff up the stack, it looks like the call is coming from generateThumbnail function. 

If a new stroke comes, I cancel the stroke in process before starting the new one. However, you got execution stuck in waitForDone. This looks like a race condition somewhere. Yikes!

Pierre, 
I made a branch with a possible fix for this problem. Could you, please, test it. The branch with the changes is this one:
https://phabricator.kde.org/diffusion/KRITA/browse/eingerman%252Foverviewdocker_bug_367901/

Tested it and drew for multiple ours (Even finished my painting)
Looks like the build from your branch works. I got some minor slowdowns when I change brushes shortly after doing a stroke, I guess that's the point when this function triggers.

I'm going to test it within the next days more so that I can confirm for sure that this fixes it.

This has been pushed to master now

Git commit 39fcfac8281d4d0bf100d4c15460fa2a2bc998ab by Dmitry Kazakov.
Committed on 29/01/2022 at 11:47.
Pushed by dkazakov into branch 'master'.

Fix Krita discarding native threads every couple of seconds

For years Krita has been spawning native threads carelessly. It
happened because of the implementation of QThreadPool::waitForDone(),
which discards threads on every successful call.

We once had a patch for that (9c34fef3320983c8e0542363121035eab225cd29),
but it has been reverted due to deadlock regressions it introduced.

This patch adds a bit different implementation of the waiting strategy,
so (I hope) it won't cause any deadlocks.
Related: bug 360677

M  +13   -0    libs/image/kis_update_job_item.h
M  +29   -4    libs/image/kis_updater_context.cpp
M  +7    -0    libs/image/kis_updater_context.h

https://invent.kde.org/graphics/krita/commit/39fcfac8281d4d0bf100d4c15460fa2a2bc998ab

Git commit 8b9ac2512e9ec12f52411c86f299ea3550936a0a by Dmitry Kazakov.
Committed on 23/02/2022 at 08:48.
Pushed by dkazakov into branch 'krita/5.0'.

Fix Krita discarding native threads every couple of seconds

For years Krita has been spawning native threads carelessly. It
happened because of the implementation of QThreadPool::waitForDone(),
which discards threads on every successful call.

We once had a patch for that (9c34fef3320983c8e0542363121035eab225cd29),
but it has been reverted due to deadlock regressions it introduced.

This patch adds a bit different implementation of the waiting strategy,
so (I hope) it won't cause any deadlocks.
Related: bug 360677

M  +13   -0    libs/image/kis_update_job_item.h
M  +29   -4    libs/image/kis_updater_context.cpp
M  +7    -0    libs/image/kis_updater_context.h

https://invent.kde.org/graphics/krita/commit/8b9ac2512e9ec12f52411c86f299ea3550936a0a