Bug 264175

Summary: After working for a while with big resolutions (9000x6000 or bigger) Krita slows suddently down with the desktop and become unstable.
Product: [Applications] krita Reporter: Ico_dY <enrico_guarnieri>
Component: GeneralAssignee: Dmitry Kazakov <dimula73>
Status: RESOLVED FIXED    
Severity: crash CC: halla
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Ubuntu   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Ico_dY 2011-01-24 15:44:29 UTC 
Application: krita (2.4 Alpha 1)
KDE Platform Version: 4.5.5 (KDE 4.5.5)
Qt Version: 4.7.0
Operating System: Linux 2.6.35-22-generic x86_64
Distribution: Linux Mint 10 Julia

-- Information about the crash:
- What I was doing when the application crashed:
I was normally painting on a single level.
The problem shows up after painting for about 30/60 minutes.

- Unusual behavior I noticed:
The desktop slows down with Krita.
Maybe is it a memory leak?
(My workstation have 8GB of memory...)

The crash can be reproduced some of the time.

-- Backtrace:
Application: Krita (krita), signal: Segmentation fault
[Current thread is 1 (Thread 0x7f27856e9780 (LWP 14135))]

Thread 4 (Thread 0x7f2774452700 (LWP 14136)):
#0  0x00007f277cea6203 in __poll (fds=<value optimized out>, nfds=<value optimized out>, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:87
#1  0x00007f277c305009 in ?? () from /lib/libglib-2.0.so.0
#2  0x00007f277c3057b5 in g_main_loop_run () from /lib/libglib-2.0.so.0
#3  0x00007f2774b890f4 in ?? () from /usr/lib/libgio-2.0.so.0
#4  0x00007f277c32a7e4 in ?? () from /lib/libglib-2.0.so.0
#5  0x00007f2784d71971 in start_thread (arg=<value optimized out>) at pthread_create.c:304
#6  0x00007f277ceb292d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#7  0x0000000000000000 in ?? ()

Thread 3 (Thread 0x7f2750571700 (LWP 14179)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
#1  0x00007f2784ffce3b in wait (this=<value optimized out>, mutex=0x5232670, time=18446744073709551615) at thread/qwaitcondition_unix.cpp:88
#2  QWaitCondition::wait (this=<value optimized out>, mutex=0x5232670, time=18446744073709551615) at thread/qwaitcondition_unix.cpp:160
#3  0x00007f2784ff8b0b in QSemaphore::acquire (this=0x5308010, n=1) at thread/qsemaphore.cpp:144
#4  0x00007f27844d69fe in KisTileDataPooler::waitForWork (this=0x5308000) at /media/sda7/Build/Koffice/koffice-src/krita/image/tiles3/kis_tile_data_pooler.cc:127
#5  0x00007f27844d6c48 in KisTileDataPooler::run (this=0x5308000) at /media/sda7/Build/Koffice/koffice-src/krita/image/tiles3/kis_tile_data_pooler.cc:156
#6  0x00007f2784ffc27e in QThreadPrivate::start (arg=0x5308000) at thread/qthread_unix.cpp:266
#7  0x00007f2784d71971 in start_thread (arg=<value optimized out>) at pthread_create.c:304
#8  0x00007f277ceb292d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#9  0x0000000000000000 in ?? ()

Thread 2 (Thread 0x7f274fd70700 (LWP 14180)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
#1  0x00007f2784ffce3b in wait (this=<value optimized out>, mutex=0x52275b0, time=18446744073709551615) at thread/qwaitcondition_unix.cpp:88
#2  QWaitCondition::wait (this=<value optimized out>, mutex=0x52275b0, time=18446744073709551615) at thread/qwaitcondition_unix.cpp:160
#3  0x00007f2784ff8dab in QSemaphore::tryAcquire (this=0x53087f0, n=1, timeout=<value optimized out>) at thread/qsemaphore.cpp:221
#4  0x00007f27844f3a6a in KisTileDataSwapper::run (this=0x5308030) at /media/sda7/Build/Koffice/koffice-src/krita/image/tiles3/swap/kis_tile_data_swapper.cpp:90
#5  0x00007f2784ffc27e in QThreadPrivate::start (arg=0x5308030) at thread/qthread_unix.cpp:266
#6  0x00007f2784d71971 in start_thread (arg=<value optimized out>) at pthread_create.c:304
#7  0x00007f277ceb292d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#8  0x0000000000000000 in ?? ()

Thread 1 (Thread 0x7f27856e9780 (LWP 14135)):
[KCrash Handler]
#6  0x0000000000000071 in ?? ()
#7  0x00007f2781e94c4f in qDeleteAll<QList<KoColorSet*>::const_iterator> (this=0x7f276c07ffe0, __in_chrg=<value optimized out>) at /usr/include/qt4/QtCore/qalgorithms.h:322
#8  qDeleteAll<QList<KoColorSet*> > (this=0x7f276c07ffe0, __in_chrg=<value optimized out>) at /usr/include/qt4/QtCore/qalgorithms.h:330
#9  KoResourceServer<KoColorSet>::~KoResourceServer (this=0x7f276c07ffe0, __in_chrg=<value optimized out>) at /media/sda7/Build/Koffice/koffice-src/libs/widgets/KoResourceServer.h:103
#10 0x00007f2781e922fa in KoResourceServerProvider::~KoResourceServerProvider (this=0x79eaa910, __in_chrg=<value optimized out>) at /media/sda7/Build/Koffice/koffice-src/libs/widgets/KoResourceServerProvider.cpp:160
#11 0x00007f277ce054f2 in __run_exit_handlers (status=0) at exit.c:78
#12 exit (status=0) at exit.c:100
#13 0x00007f277cdead95 in __libc_start_main (main=<value optimized out>, argc=<value optimized out>, ubp_av=<value optimized out>, init=<value optimized out>, fini=<value optimized out>, rtld_fini=<value optimized out>, stack_end=0x7ffff8b2e998) at libc-start.c:258
#14 0x00000000004008b9 in _start ()

Reported using DrKonqi
Comment 1 Halla Rempt 2011-03-26 11:46:55 UTC 
All performance bugs on big images are for dmitry :-). I haven't had a crash yet, but I did experience lag and halting when using a 10000x10000 image for a while
Comment 2 Dmitry Kazakov 2011-03-27 15:20:53 UTC 
Git commit f20afb78a889e6fd0c15a1024a8a24090b3e62b1 by Dmitry Kazakov.
Committed on 27/03/2011 at 15:19.
Pushed by dkazakov into branch 'master'.

Fixed a memory leak in the pooler

We can't just clear the clones stack as it stores pointers only. We
need to delete every item personally.

CCBUG:264175

M  +5    -1    krita/image/tiles3/kis_tile_data.cc     
M  +4    -1    krita/image/tiles3/kis_tile_data.h     

http://commits.kde.org/calligra/f20afb78a889e6fd0c15a1024a8a24090b3e62b1
Comment 3 Dmitry Kazakov 2011-03-27 15:24:03 UTC 
Did you use a version of Krita dated after the 20th of March? If yes, then the bug is probably fixed by the commit above.
Comment 4 Ico_dY 2011-03-28 13:13:32 UTC 
I've just tested it again and everything now works perfectly without slowdowns.
Nice job, Dmitry! ;-)