https://bugs.kde.org/show_bug.cgi?id=388854
--- Comment #37 from Tobias Deiminger <haxti...@posteo.de> --- (In reply to Tobias Deiminger from comment #36) > After sleeping over it, I can't believe my own words. How could uchar* > QImageData::data happen to point to stack? Give me some time to double check > and correlate with /proc/pid/maps. Pixmap data was not on stack, nor in the [heap] mapping from /proc/pid/maps. That's why I couldn't find the chunk. It actually was in an separate anonymous memory mapping. man 3 malloc gives hints why there may be more anonymous mappings (in addtion to [heap]): - "When allocating blocks of memory larger than MMAP_THRESHOLD bytes, the glibc malloc() implementation allocates the memory as a private anonymous mapping...MMAP_THRESHOLD is 128 kB by default" - "in multithreaded applications, glibc creates additional memory allocation arenas if mutex contention is detected. Each arena is a large region of memory that is internally allocated by the system (using brk(2) or mmap(2))" So, no bug with that. Regarding the reported memory leak story, it looks like Albert is right. 1) I can observe a fast heap increase until page pixmap cache is fully populated (~ 142MB in my 20 page document test). => no bug, but intended caching 2) I can observer further continuous heap increase at slower rate on scrolling after that. This looks like memory leak at first sight. But when I inject a malloc_trim(0) with gdb in this situation, the memory usage immediately goes back to 142MB. => No bug, but libc "smartness". Looks fine until here. If we find memory increase even with repeated malloc_trim(0), it would indeed be worrying. I'll continue to test and see if something like this occurs. -- You are receiving this mail because: You are the assignee for the bug.
