Okular is designed to cache pixmaps of pages in RAM for faster viewing. In order to prevent it from using too much RAM for its cache, it dynamically trims the cache based on the amount of free RAM. However the code that calculates the amount of free memory is subtly flawed, occassionally with spectacular consequences. From DocumentPrivate::getFreeMemory in document.cpp: // read /proc/meminfo and sum up the contents of 'MemFree', 'Buffers' // and 'Cached' fields. consider swapped memory as used memory. For various reasons, Linux counts SysV shared memory as "Cached" memory even though unlike real cache it can't ever be discarded as a result of memory pressure. So when there's lots of SysV shared memory in use okular overestimates how much memory is free. This wouldn't be an issue, except that at least on my system Okular's cache seems to itself be stored as SysV shared memory and is therefore itself counted as free by Okular. Under the right circumstances this can apparently help bring a system to its knees. Reproducible: Didn't try Steps to Reproduce: Probably not trivially reproducable. I noticed there was a problem after about a month of uptime with numerous copies of Okular open, heavy use of search within multi-hundred-page documents, etc. Due to the way Okular decides to free images from its cache, reproducing this fully probably also requires much more RAM than swap and another shm-hogging application to confuse Okular initially. Actual Results: About half of my available 12 gigabytes of RAM was consumed by shared memory, of which Okular instances were responsible for about 2-3 GB. I noticed there was a problem when the system started swapping to the point of unusability despite half of the RAM superficially appearing to be free. The Linux OOM killer helpfully failed to kill the offending apps, instead killing other applications and helping to free up more memory for them. Expected Results: Okular should have detected that the system was running low on memory and dropped its caches. Gentoo x86-64, Qt 4.8.4
Thanks for your detailed report, unfortunately i'm not sure i fully understand what you are saying. Since it seems you are technical enough (you got to read the code) do you think you could provide a patch for the function or at least some kind of pseudo-code of what it should and should not do?
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!