Bug 367901

Summary: Overview Dock causes freeze
Product: [Applications] krita Reporter: Pierre "bloodywing" Geier <bloodywing>
Component: DockersAssignee: Krita Bugs <krita-bugs-null>
Status: RESOLVED FIXED    
Severity: crash CC: geneing, halla, null
Priority: NOR    
Version: git master (please specify the git hash!)   
Target Milestone: ---   
Platform: Compiled Sources   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: My Krita ebuild
GDB Backtrace right after the freeze

Description Pierre "bloodywing" Geier 2016-08-27 14:58:27 UTC
After a around an hour with the overview dock floating krita freezses.

Steps to reproduce:

1. Overview Dock has to be visible and undocked from the toolbar just floating around
2. Draw a while. I'm using canvas sizes with 16 bit and at least 3000px on the longest side

Krita will freezes after a while now the brush cursor will remain at some paint on canvas and the whole GUI will stop updating anything. Only exception your actual cursor, if you hover edges that are resizeable within the program (like the floating overview dock) it will change.
Comment 1 Unknown 2016-08-28 05:05:39 UTC
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?
Comment 2 Pierre "bloodywing" Geier 2016-08-28 09:26:51 UTC
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
Comment 3 Pierre "bloodywing" Geier 2016-08-28 09:27:45 UTC
Created attachment 100814 [details]
My Krita ebuild
Comment 4 Pierre "bloodywing" Geier 2016-08-28 13:15:19 UTC
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.
Comment 5 Unknown 2016-08-29 07:10:09 UTC
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.
Comment 6 Unknown 2016-08-29 07:10:36 UTC
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.
Comment 7 Pierre "bloodywing" Geier 2016-08-30 19:22:48 UTC
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.
Comment 8 Pierre "bloodywing" Geier 2016-08-30 19:23:33 UTC
Created attachment 100853 [details]
GDB Backtrace right after the freeze
Comment 9 Gene 2016-08-30 22:35:09 UTC
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!
Comment 10 Unknown 2016-08-31 05:18:42 UTC
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/
Comment 11 Pierre "bloodywing" Geier 2016-08-31 20:21:08 UTC
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.
Comment 12 Halla Rempt 2016-09-02 09:01:21 UTC
This has been pushed to master now
Comment 13 Dmitry Kazakov 2022-01-29 11:47:33 UTC
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
Comment 14 Dmitry Kazakov 2022-02-23 08:49:45 UTC
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