https://bugs.kde.org/show_bug.cgi?id=226678
--- Comment #9 from Christoph Feck <cf...@kde.org> --- Needs a heaptrack or valgrind log to verify that there is actually a memory leak. I guess glibc simply doesn't resize the heap on every free() for performance reasons. Additionally, if something was allocated after the thumbnail allocations, freeing them cannot resize the heap. I think there are variables to tune glibc's allocator, but since parsing them is expensive, these are not environment variables. A workaround would be to use mmap() for memory chunks, but the number of maps the kernel allows per process is limited. -- You are receiving this mail because: You are watching all bug changes.
