I just noticed with System Monitor opened in Kubuntu 20.04 when I open Krita, create a new file, brush around just to give some pixel information to the canvas and then if I ctrl + layer miniature click to select opaque it selects but it also takes a lot more memory in the System Monitor.
Now, I’d understand it’s more info but deselecting doesn’t lower the memory usage and if I select opaque again (without any changes or any other action in between select opaque -> deselect - >select opaque again) the memory goes significantly up again.
I mean in my case for example 4 times selecting and deselecting opaque led to 400 MB increase in memory which is a lot. Obviously de/selecting more leads to GBs of memory used never released.
Just to be sure I gave it an hour to see if some memory management is in place that takes longer to kick in or something but no change.
I’m on Krita appimage 4.4.1, I also downloaded the 4.4.2 beta2 and 4.4.3alpha appimages but the result is the same (actually I think it increases faster in beta2 than in 4.4.1 but I haven’t calculated the difference so it might be just my feeling and it’s the same in both).
LEAK SUMMARY:
definitely lost: 121,088 bytes in 826 blocks
indirectly lost: 12,114,965 bytes in 10,882 blocks
possibly lost: 33,850,986 bytes in 120 blocks
still reachable: 13,778,758 bytes in 17,183 blocks
of which reachable via heuristic:
newarray : 1,640 bytes in 7 blocks
suppressed: 0 bytes in 0 blocks
For counts of detected and suppressed errors, rerun with: -v
ERROR SUMMARY: 23229 errors from 611 contexts (suppressed: 46 from 4)
LEAK SUMMARY:
definitely lost: 124,012 bytes in 900 blocks
indirectly lost: 3,446,140 bytes in 4,656 blocks
possibly lost: 42,114,525 bytes in 4,785 blocks
still reachable: 14,961,980 bytes in 25,064 blocks
of which reachable via heuristic:
newarray : 4,264 bytes in 1 blocks
multipleinheritance: 3,072 bytes in 2 blocks
suppressed: 0 bytes in 0 blocks
For counts of detected and suppressed errors, rerun with: -v
ERROR SUMMARY: 26037 errors from 4155 contexts (suppressed: 32545 from 5)
LEAK SUMMARY:
definitely lost: 127,516 bytes in 925 blocks
indirectly lost: 6,569,991 bytes in 12,685 blocks
possibly lost: 39,683,056 bytes in 291 blocks
still reachable: 9,834,226 bytes in 21,504 blocks
of which reachable via heuristic:
multipleinheritance: 3,072 bytes in 2 blocks
suppressed: 0 bytes in 0 blocks
For counts of detected and suppressed errors, rerun with: -v
ERROR SUMMARY: 21841 errors from 643 contexts (suppressed: 38 from 4)
According to valgrind documentation:
definitely lost means your program is leaking memory – fix those leaks!
120~127KB lost, that’s nothing
indirectly lost means your program is leaking memory in a pointer-based structure. (E.g. if the root node of a binary tree is “definitely lost”, all the children will be “indirectly lost”.) If you fix the “definitely lost” leaks, the “indirectly lost” leaks should go away.
possibly lost means your program is leaking memory, unless you’re doing unusual things with pointers that could cause them to point into the middle of an allocated block; see the user manual for some possible causes. Use --show-possibly-lost=no if you don’t want to see these reports.
According to memory lost, this is more a possible source of bugs than a real problem with memory leak I think.
still reachable means your program is probably ok – it didn’t free some memory it could have. This is quite common and often reasonable. Don’t use --show-reachable=yes if you don’t want to see these reports.
Ok, they tell it’s not important because quite common
For what I understand, this memory is still marked as occupied by system even after application is closed.
Value here is not so important.
In the last case, my Krita process use at its maximum 2.5GB memory.
And difference between the most basic usage (start/stop krita) and a more complex usage is very small.
There’s some memory lost that’s sure, but it’s nothing compared to real memory usage when you paint.
Notes:
During drawing and selection operations, no memory error are returned by valgrind
Most of problems are detected at startup (Python 3.8 libs generate many errors…)
Concerning the memory not ‘free-ed’, you’ll find here an explanation about memory allocation/de-allocation and heap, that can explain why you have the impression that memory is not free-ed after usage:
And here, from documentation about free() function in C:
Occasionally, free can actually return memory to the operating system and make the process smaller. Usually, all it can do is allow a later call to malloc to reuse the space. In the meantime, the space remains in your program as part of a free-list used internally by malloc.
There is no point in freeing blocks at the end of a program, because all of the program’s space is given back to the system when the process terminates.
