[okular] [Bug 388854] Okular uses a very large amount of RAM for caching

[Tobias Deiminger]

https://bugs.kde.org/show_bug.cgi?id=388854

--- Comment #37 from Tobias Deiminger <haxtibal at 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.