Version: (using KDE 4.1.3) OS: Linux Installed from: Ubuntu Packages When viewing djvu documents, memory used by the X server grows as you render new pages. I've tested with the X org server that comes with Kubuntu 8.10 (X Server 1.5.2) and with Xming on Windows 2000 (okular running on Kubuntu). After browsing 30 pages or so, Xming's memory usage growed from 8 MB to 200 MB. Similar increases are observed on the X server of Kubuntu. After okular is closed, the X server(s) return memory to the system. If you keep browsing a large document, eventually the systems becomes memory-starved and unstable.
Can you attach or send me "a large document" where you were able to reproduce this problem?
The problem, as it seems, is not restricted to the djvu backend. A large pdf shows it too: Open a large pdf document, such as http://open-std.org/JTC1/SC22/WG21/docs/papers/2008/n2588.pdf Press the PageDown key and keep it pressed. Keep an eye on `top` or other memory reporting tool, looking at the Xorg process. On the Kubuntu machine, the memory skyrockets after reaching around page 500, but the X process already was using 700 MB of RES memory, so maybe some empty buffers were filled before requesting new memory. This high memory usage of X is something I'm investigating and it's the way I found the problem with Okular. I've observed that sometimes not all the memory used by X is freed after Okular closes, so this memory can be a remannt from previous Okular sessions. To make less plausible the hypothesis of a bug on the X server distributed with Kubuntu 8.10, tried another X server: xming 6.9.0.23 running on Windows 2000. Okular was ran on the Kubuntu machine as okular --display ahost:0 thedoc.pdf The memory consumption was evident: starting at 23MB when Okular is executed, it reaches 200 MB after scrolling 70 pages. xpdf, with the same document, does not change the memory used by the X server no matter how much pages are displayed.
> The memory consumption was evident: starting at 23MB when Okular is executed, > it reaches 200 MB after scrolling 70 pages. Okular keeps a cache of the browser pages, so it is quite obvious the memory grows (especially when your system has much memory available). If you want to reduce the cache used, you can set it in the configuration: Settings -> Configure Okular -> Performance. Furthermore, Okular frees all the memory used when being closed, even X pixmaps: thus, if your X server has more memory used when closing Okular, then this is an X issue.
We cache the pixmaps but we should never reach level of eating all the memory. Which platform are you using?
Asking on the X.org mailing list [1] yield this information: The X server does nothing fancy when resources such as pixmaps are deallocated. Is up to the C library function free() to return memory to the OS. Heap fragmentation can happen, thus preventing free() from returning memory to the OS. So using the X server for caching pages can indeed cause an unbounded growth of the amount of memory asigned to the X server process. [1]: http://thread.gmane.org/gmane.comp.freedesktop.xorg/34751
I can reproduce this bug using KDE 4.2.0 on gentoo amd64. I can easily make X use over 600MiB just by scrolling for a minute or two. Setting "Memory Usage" to "Low" seems to help it, though.
The situation is much worse than described in this bug report. - X server resident usage climbs to 500MB and virtual memory usage to about 1.3MB on my system. - The X server memory is NOT consistently freed when okular exits. This results in serious thrashing. This appears to be related to okular sharing its pixmap cache among separate okular instances, such that the total memory used by all okular instances is capped at 160MB (until things go wrong) using some sort of X server shared memory. Given that okular appears to share pixmaps between instances, this does not appear to be just an X server issue. Shared memory mechanisms tend to have semantics that allow resource consumption to persist after a process exits. This is an X bug AND an okular bug. Okular performance is set to normal. Ironically, the resource consumption appears to be related to an attempt to limit resource consumption across instances. If you weren't sharing pixmaps, running multiple instances of okular would result in huge consumption but it would be consistently released when all instances were closed. More details here (in the many comments by me at the end): https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/98783 ii okular 4:4.2.2-0ubunt document viewer for KDE 4 Distributor ID: Ubuntu Description: Ubuntu 9.04 Release: 9.04 Codename: jaunty
(In reply to comment #7) > - The X server memory is NOT consistently freed when okular exits. This is an Xorg bug. > This appears to be related to okular sharing its pixmap cache among separate > okular instances, This is not true, Okular does not share the pixmaps of an open document with any other open document. Furthermore, all the (still cached) pixmaps of a document are freed when that document is closed.
(In reply to comment #8) > (In reply to comment #7) > > - The X server memory is NOT consistently freed when okular exits. > > This is an Xorg bug. It is a QoI (qualitiy of implementation) issue on the X server, not necessarily a bug. Nevertheless, it is affecting okular users. Other pdf/djvu viewers are not affected by this problem. This diminishes the value of okular compared against those other viewers. The problem is very serious when you are using okular on a remote X server with low memory while okular runs on a machine with lots of RAM: my case when reading docs on a 1 GB X server with okular running on a 8 MB machine. Eventually, the X server starts swapping and becomes very slow. Which lead us to the crux of the issue: okular developers explained to me that the agressive usage of X server pixmaps is geared towards fast perfomance showing pages. After months using okular with the Low memory setting, I've never experienced slowness. Actually, either with the Low memory setting or with the Normal setting it feels as fast as xpdf, for instance, which does not use the pixmap trick at all. This experience includes remote X sessions over slow wifi networks. So, unless someone can justify the superiority of the pixmap approach on terms of improved reading experience (not just raw displayed-pages-per-minute, we are talking about displaying a static image for reading) I humbly suggest to use the Low memory setting as the default or, better, do not use the pixmap trick at all. The memory used by the X server grows with the Low memory setting too, although much less than the Normal setting, where is no rare to see the X server's memory reaching gigabyte levels after some days of light usage. You can argue that it is an Xorg problem (it really is an Xorg problem that you are storing 1 GB of pixmaps on the X server?) but okular users will perceive it as a okular problem.
No arguing at all, if we free the pixmaps and that memory is not freed, it's not *our* bug, so put the strain on people causing the problem, not on us. Of course your experience of using "remote X sessions over slow wifi networks." is not comparable at all with people running a local X server, for those people using pixmaps is visibly faster. The fact is that they are two totally different use cases and probably one can't do a program that will make both kind of users happy, people running local X servers want eye candy, speed at all costs, etc. People running remote/shared X servers want the less use of resources possible. I don't really see us changing this as it works fine for most of our users (you'll agree that people using "remote X sessions over slow wifi networks." is not a majority) but i am not sure if *i* (not the okular maintainer) would opose to a clean patch implementing non pixmap usage
(In reply to comment #10) > No arguing at all, if we free the pixmaps and that memory is not freed, it's > not *our* bug, so put the strain on people causing the problem, not on us. OSes, libraries, services, all have bugs. If a bug on a third-party piece of software is causing problems to the users of my application, and I cannot directly fix it, I'm interested on implementing a workaround. Not doing so is bad for my users. OTOH, putting hundreds of megabytes of pixmaps on the X server looks like abusing it. We can say that okular is the most memory hungry document viewer out there (at least on Normal memory setting). The fact that the memory is used by the X server is irrelevant: you can cause a huge memory consumption by just advancing page by page on a large document. It's true that the X server may not return the memory to the OS, but it's true too that at some point an instance of okular may be using more than 500 MB of memory (I've seen this). This is not right by any means. Hence my request for setting the Low memory setting as the default one, or throwing out the pixmap usage. > Of course your experience of using "remote X sessions over slow wifi networks." > is not comparable at all with people running a local X server, for those people > using pixmaps is visibly faster. The fact is that they are two totally > different use cases and probably one can't do a program that will make both > kind of users happy, I'm "both kind of users". I'm trying to say that, right now, I've not found a circunstance where okular is faster than other document viewers. Faster enough to notice so that it makes a difference when looking at the document, not when just seeing how the screen flashes while the pages change. > people running local X servers want eye candy, speed at > all costs, etc. People running remote/shared X servers want the less use of > resources possible. > I don't really see us changing this as it works fine for most of our users > (you'll agree that people using "remote X sessions over slow wifi networks." is > not a majority) Most of my okular usage is on a local machine, so there is no need to paint me as a corner case. OTOH, I recall that on irc you precisely explained that pixmaps are useful for limiting bandwith usage, as once a page is on the X server, viewing it again would not cause an image transfer. So now pixmaps are intended for fast local viewing? Well, maybe you can point me to a document which display is annoyingly slow on xpdf or evince and "fast enough" on okular thanks to the pixmap trick on okular. > but i am not sure if *i* (not the okular maintainer) would > opose to a clean patch implementing non pixmap usage Last time I offered to create such patch the maintainer answered with a resounding NO.
(In reply to comment #11) > (In reply to comment #10) > We can say that okular is the most memory hungry document viewer > out there (at least on Normal memory setting). The fact that the memory is used > by the X server is irrelevant: you can cause a huge memory consumption by just > advancing page by page on a large document. It's true that the X server may not > return the memory to the OS, but it's true too that at some point an instance > of okular may be using more than 500 MB of memory (I've seen this). This is not > right by any means. Hence my request for setting the Low memory setting as the > default one, or throwing out the pixmap usage. Okular dynamically adapts its memory usage depending on the total memory and the available memory, updating its stats. The memory profile determine how Okular will use the available memory for caching: Low is "I don't cache what I don't show", Normal is "I cache something I have visited, but not much" and Aggressive is "cache almost everything can fit in the free RAM". Also, independently than the memory profile, if the free memory available reduces a lot (for example you start kontact, evolution, openoffice.org, etc), Okular reduces the content of its cache. 500MB could even be normal, if the available RAM prior starting that Okular instance was like 1GB and the memory profile is eg Normal. > OTOH, I recall that on irc you precisely explained that > pixmaps are useful for limiting bandwith usage, as once a page is on the X > server, viewing it again would not cause an image transfer. Correct. > So now pixmaps are intended for fast local viewing? That as well, as you avoid (or reduces a lot) doing the "in RAM"->"in X server" pixmap conversion (as you need to have X pixmaps to draw something on the X server), which is slow and synchronous (so blocks the whole X server during the conversion). > > but i am not sure if *i* (not the okular maintainer) would > > opose to a clean patch implementing non pixmap usage > > Last time I offered to create such patch the maintainer answered with a > resounding NO. Wasn't a "resounding NO", but a "won't be done if it's just to workaround Xorg problems".
Okular is not the most memory hungry document viewer out there, at least it's at the same level of kpdf ;-) It's fast for local viewing because to paint anything on X, it must be a X pixmap, if you already have a X pixmap you just have to paint it, if you have something else, you have to create one and then paint it. And creating X pixmaps is not a negligible time. And it's not about page rendering (that is creating the image that represents the page) speed it's about drawing speed (that is putting that image in front of the user), it's different, page rendering speed is going to be the same as that's all done in the CPU it's drawing speed of a rendered page that is much snappier. And probably you got a NO because you weren't attacking the problem from the correct point, if you suggest removing page caching or not using X pixmaps by default obviously you get a no, if you suggest having a hidden setting that disallows the use of non local memory, that would different. But now that i think i'm not sure it makes sense, because once you've disallowed any X pixmap caching even if you don't explicitely use X pixmaps for rendering you are going to use them implicetely because it's the only thing that can be rendered, so you won't gain anything at the end, it'll have the same remote memory usage at the end.
> This is not true, Okular does not share the pixmaps of an open document with > any other open document. Furthermore, all the (still cached) pixmaps of a > document are freed when that document is closed. The behavior of okular is not consistent with either of your assertions. - X server memory increases by 160MB whether you are running one instance of okular or multiple instances. If it did not share, it would grow by 160MB * number of instances. Unless you send a signal to other instances to reduce memory usage before allocating more. - In some circumstances, those pixmaps clearly are not freed. Perhaps okular tries but there are some circumstances where it is omitted. It is more likely that an application forgets to request that the memory is freed than that the X server fails to actually release it without reporting an error. This is common due to exceptions, assert(), more than one exit(), signals, alternate code paths, etc. What makes you so sure they are ALWAYS freed on exit? Which alternate code paths have you taken into account? Have you actually checked that the algorithm for freeing doesn't have bugs? If your assertions are actually true, then you need to provide an alternate explaination as to why the application behaves in the manner which suggests that they are false. You need to explain: - Why memory usage is capped across instances - How okular allocates its X server side pixmaps. What functions does it call, from which functions in which source files. - When and how okular deallocates its pixmaps. What functions does it call, from which functions in which source files. - What the limits are for number of cached pixmaps or total size of cached pixmaps. - Why memory isn't freed when the application exits. Something a little more concrete than just saying it is an X server bug. At least try to narrow the scope a little. Why is it that your memory isn't freed on exit when other application's server memory seems to be. What is unusual about your use of pixmaps compared to other apps. Do you know of any other apps that use pixmaps in a similar fashion that we can try? This applies specifically to the pixmaps used to store the pages. The amount of memory used seems to be more consistent with rendered pages than icons, etc. And it applies specifically to the pixmaps stored on the server, not on the client. The shared pixmaps hypothesis at least explains the observed phenomenon. Your denial explains nothing. 160MB as a trigger point for garbage collection (with total X memory not being released until then) doesn't seem to be consistent with the fact that once a leak has occurred, X server size continues to grow. Note that evince doesn't seem to have this problem. Give me something specific to go on and I will see if I can get a chance to look at the source. But I am not going to dig for hours just to find out where your application uses the pixmaps. Gotta go.
I can certainly appreciate that X pixmap storage on the server could significantly improve performance in many cases. Indeed, okular seemed a bit faster than evince at first, which was largely why a switched. But in the long range memory consumption ultimately causes it, and the rest of the system, to be slower. This would not be the case on a system with ample ram. And the sharing pixmap cache feature, if it actually exists, or an equivalent mechanism with the same effect would be a very good thing in terms of keeping the ram cache reasonable by caching just the document the user is currently paging through. And I care about the performance because I skim documents at very high speed to find what is relevant. Often as fast as the viewer can rasterize the pages. I regularly use huge documents, often many at the same time. Albert: having a (non-hidden) setting to disable pixmap cache on the server could help, in the situations it is needed for. You would simply reuse one or two pixmaps to render either the visible area or the page or two that occupies it. Since only one or two pages would be cached on the server, each instance would use little memory there. If you have 10 instances, you only have 10 or 20 pages stored on the server (still a lot if you use 24bit mode) If that pixmap doesn't get freed, it takes a lot longer for the system to become unstable. You reuse those pixmaps. But this ends up being very close to just setting cache_size=2, if the cache is made of non-sharable pixmaps. I.E. the degeneration case of the cache would more or less do what you would do if you weren't caching. The real minimum X server memory usage case is when you bitblt the bottom portion of the top page and the top portion of the bottom page (assuming a typical case where part of two pages is visable) from a client side pixmap directly to the framebuffer and scroll by using a bitblt to move the memory up (or down) and then a small bitblt to fill in the missing piece. Things get more complicated, though, when part of the window is obscured. And applications sometimes have subtle errors in the update code. Or you can bitblt into the back buffer, then let X copy to the window. Easier because you don't have to worry about obscuring windows (which may even move on you) in either the draw or the scroll operations. But it may be easier, and ultimately more beneficial, to carefully check for bugs in the cache handling than to write new code which could result in the old set of bugs plus a new set. The statement that okular reduces its cache use based on available system memory might explain why the usage caps at 160MB on my machine. Yet free memory is a nebulous concept on a system which uses virtual memory and fills any unused memory with disk buffers. And there is the timing of exactly when this reduction of cache occurs.
Are there any activity in this issue? I can confirn that okular still uses makes X to use 2GB of memory.And this memory does not become free after closing okular. it's happen on okular 0.9 in kde4.3 and xorg-server-1.6.3
*** Bug 193675 has been marked as a duplicate of this bug. ***
*** Bug 209591 has been marked as a duplicate of this bug. ***
*** This bug has been confirmed by popular vote. ***
Gentoo amd64, KDE 4.4.1, Xorg-server 1.7.5. Left yesterday Okular open. For a night X memory consumption grown from 50 to 800 Mb. Closing Okular freed 50 Mb from X, so something like 700 Mb of leaked memory. Nice.
And the evidence that Okular is the one at fault is where? Because i've run valgrind over and over and never could find any memory leak.
(In reply to comment #21) > And the evidence that Okular is the one at fault is where? Because i've run > valgrind over and over and never could find any memory leak. Xrestop is good enough ? Before closing okular, it showed that most memory amount was used by okular. Can you tell me what to do with valgrind, and i'll give output.
xrestop will be of use if you can prove that okular memory usage raises while doing nothing with it. for valgrind it's easy, do valgrind --leak-check=full okular and then look at the figures it gives at the end.
I didn't tell that "okular memory usage raises while doing nothing with it." I told that okular used X for caching(?) 700 mb, and after closing okular memory (700 mb) is not free. And xrestop shows that X already not storing okular pixmaps. Ok. I'm installing valgrind. I'll post here if it show something. Although as i understood from discussion above, it's problem with X freeing pixmaps. I'm not programmer, i have no idea who's mistake is that: bug in X or wrong usage of X cache by okular. All i know okular usage is draining memory.
(In reply to comment #21) > And the evidence that Okular is the one at fault is where? Because i've run > valgrind over and over and never could find any memory leak. How is valgrind relevant here? This bug is not about a memory leak in okular, but about okular allocating hundreds of MBs of pixmaps on the X server.
#25 to me it's fairly obvious, each time you allocate a X pixmap in the server side you get a handle in your process, if you don't free the local handle there is a local leak, if you do not leak it, it means you freed the X pixmap too. But as it seems you have a better idea i'm open to your suggestions. And well, if the bug is about okular allocating X memory we can close it altogether because that is not a bug at all.
(In reply to comment #26) > And well, if the bug is about okular allocating X memory we can close it > altogether because that is not a bug at all. Yeah. It's not bug, it's feature. Just need to add to changelog: now okular not only open pdf, but also help you to get rid out of your memory. Seriously, even if okular doing everything right, at the end we have memory leak. It's bug. If guys from X don't want to patch, so okular team need to create workaround . Cause right now after using okular people have to restart. If it's not bug for you guys, i don't know what can be.
#27 Being sarcastic is not going to make people help you so spare ourselves that comments everyone will be happier. It being a bug i agree, but we still have to find whose fault it is before we can fix it.
(In reply to comment #26) > #25 to me it's fairly obvious, each time you allocate a X pixmap in the server > side you get a handle in your process, if you don't free the local handle there > is a local leak, if you do not leak it, it means you freed the X pixmap too. > > But as it seems you have a better idea i'm open to your suggestions. > > And well, if the bug is about okular allocating X memory we can close it > altogether because that is not a bug at all. This was discussed on the past. The X server (all X servers I know) are not so smart managing resources that they can cope with the usage pattern okular does. Even if okular frees all handles, the X server sometimes does not give back to the OS all the allocated memory, and then fragmentation can prevent reusing that memory on another okular session. This is not a problem with most X applications, because the amount of allocated X resources is low (compared with okular). As mentioned on the past too, I did some informal benchmarks and perceived no speed difference on page rendering after changing Okular's memory usage setting, nor I perceive differences with other pdf viewers (xpdf, for instance). What I observe is performance degradation when X ends having gigabytes of allocated memory after heavy use of okular with the "normal" memory usage setting. This is a critical issue when the X server is a machine wiht 1 GB of RAM and the X client has 8 GB: after browsing a few hundred pages the X server starts paginating and finally crashes due to lack of memory. So, it is not a bug on okular itself, but a QoI (quality of implementation) issue. The X server is not as smart is we would like it to be; okular is abusing the X server when it allocates hundreds of MBs of pixmaps; sometimes this usage pattern ends on serious performance degradation or crashes. So, why don't you set the default setting to "low memory usage"? You claimed on the past that the current setting was chosen due to the performance improvement that it provides. My experience shows that there is no such improvement. Perhaps you can show a case that justifies the huge memory usage?
(In reply to comment #29) > As mentioned on the past too, I did some informal benchmarks and perceived no > speed difference on page rendering after changing Okular's memory usage > setting, nor I perceive differences with other pdf viewers (xpdf, for > instance). Your personal benchmarks are not our personal benchmarks nor other people's benchmarks. > This is a critical issue when the X server is a machine > wiht 1 GB of RAM and the X client has 8 GB: after browsing a few hundred pages > the X server starts paginating and finally crashes due to lack of memory. This is another issue, unrelated to this one. Please keep it separate. > So, why don't you set the default setting to "low memory usage"? You claimed on > the past that the current setting was chosen due to the performance improvement > that it provides. My experience shows that there is no such improvement. See first phrase above.
(In reply to comment #30) > (In reply to comment #29) > > As mentioned on the past too, I did some informal benchmarks and perceived no > > speed difference on page rendering after changing Okular's memory usage > > setting, nor I perceive differences with other pdf viewers (xpdf, for > > instance). > > Your personal benchmarks are not our personal benchmarks nor other people's > benchmarks. Thanks for making this a constructive discussion. :-/ > > This is a critical issue when the X server is a machine > > wiht 1 GB of RAM and the X client has 8 GB: after browsing a few hundred pages > > the X server starts paginating and finally crashes due to lack of memory. > > This is another issue, unrelated to this one. Please keep it separate. Well, if you don't see the relation, I give up. It is obvious that you are too proud of the "genial" idea of using the X server as a cache for Okular and are not willing to admit that it has some serious drawbacks. As far as I'm concerned, do with this bug report whatever you please.
(In reply to comment #31) > (In reply to comment #30) > > (In reply to comment #29) > > > As mentioned on the past too, I did some informal benchmarks and perceived no > > > speed difference on page rendering after changing Okular's memory usage > > > setting, nor I perceive differences with other pdf viewers (xpdf, for > > > instance). > > > > Your personal benchmarks are not our personal benchmarks nor other people's > > benchmarks. > > Thanks for making this a constructive discussion. :-/ Right, because claiming "I did some generic benchmarks so change the behaviour" is constructive? > > > This is a critical issue when the X server is a machine > > > wiht 1 GB of RAM and the X client has 8 GB: after browsing a few hundred pages > > > the X server starts paginating and finally crashes due to lack of memory. > > > > This is another issue, unrelated to this one. Please keep it separate. > > Well, if you don't see the relation, I give up. Right, I don't see the relation. The issue you mentioned could be fixed even still with Okular using X. > It is obvious that you are too > proud of the "genial" idea of using the X server as a cache for Okular and are > not willing to admit that it has some serious drawbacks. Don't be ridicolous and put words in our mouths or ideas in our minds which are *not* ours.
+1 vote for making the "MemoryLevel" option "Low" by default :)
"MemoryLevel" option "Low" draining memory too.
I can't use okular because of this behaviour (even when using the 'Low' setting). +1 for adding an option to disable this from the app or when compiling okular. P.S. Yes I know this isn't a bug in okular but nevertheless a workaround should be created.
I have been doing some digging and managed to get Firefox not to store pixmaps in X11, and removed comic strip plasmoid because it seemed to store those pixmaps in X11 too. So now when I open two okular sessions and scroll through over 600 page pdfs one after another and then close them, there's a little lag before the X11 RES goes back to normal (from 1500mb to 89mb (was 56mb before the test) but still a far cry from 1500mb :) but still it does free 'em. This when using the 'Normal' memory usage setting :) in okular.
This problem happens to me only using proprietary fglrx driver. No high memory consumption with oss radeon.
Sorry forgot to mention my specs: Arch 64-bit, Qt 4.6.3, Xorg-server 1.81.902, KDE 4.5.1, Nvidia binary blob 256.53
Another Arch 64 user with Nvidia 260.19.12, Qt 4.7.1 Xorg-server 1.9.2-1 KDE 4.5.3 X takes up around 60 MB on login and will usually bloat to around 180 MB if I open a couple PDFs in Okular. Unfortunately it doesn't deflate much at all when I close Okular. Right now it was just 168 MB. I opened up a datasheet for the ATMega32 and page up/down through the whole thing on Overview mode and X bloats to 414 MB. Closing it brought it down to 156 MB. Okular's memory option is at "Low". As you scroll up and down it increases memory consumption almost like it has forgotten that it already had pixmaps stored in X and is adding redundant ones. I'm in favour of the compile time option mentioned in #35 if posible and let the distros decide. Else a hidden option that can be put in the okularrc config file.
I'm in favor of blaming the drivers for that given comments from #37 and my own experience (works for me) Can those that have the problem see if running okular with "--graphicssystem raster" in the command line helps?
Same config as #39 here and the same experiences. What makes it even worse is that using okular constantly fills my swap partition although there is plenty of free RAM.
(In reply to comment #40) > I'm in favor of blaming the drivers for that given comments from #37 and my own > experience (works for me) > > Can those that have the problem see if running okular with "--graphicssystem > raster" in the command line helps? This doesn't help here. Swap is filled up with this option, too. In addition: With our without this option memory isn't set free after closing okular.
any news about this bug? okular still obuses the xserver in kde 4.6.1 and fills up the ram after some time of usage ....
For me, it is happens with proprietary drivers (nvidia and fglrx). For instance, in my notebook with Intel 945GM the memory usage is normal. The same for xorg-ati drivers. Unfortunately, with opensource drivers my other laptop (radeon HD4670) suffer overheating, so I have to use fglrx and adobe reader. IMHO, this "bug" should be solved. Regards, Waldo 2011/3/20 <rauchwolke@gmx.net> > https://bugs.kde.org/show_bug.cgi?id=177213 > > > > > > --- Comment #43 from <rauchwolke gmx net> 2011-03-20 16:24:00 --- > any news about this bug? okular still obuses the xserver in kde 4.6.1 and > fills > up the ram after some time of usage .... > > -- > Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are on the CC list for the bug. >
I can reproduce this with a ps file, but not with a pdf file. In ps files, I can increase the memory to 1.5 GB RAM withing 1 second fast scrolling. The same file as pdf has only very few memory usage. Albert, Pino, are there differences with respect to memory allocations here?
@Dominik: Should not be, so you are either seeing a bug in gs, in the libspectre code or in the okular-spectre code
May I suggest something that's working nicely for Firefox: we have a special about:memory page reporting on memory usage; it used to be of little use, but if you try current Nightly, it's been greatly expanded as a lot of code has been instrumented to report on all kinds of allocations. https://bugzilla.mozilla.org/show_bug.cgi?id=633653 It works great for stuff like the X pixmaps being discussed here, because while the system is not good at telling you where the allocations come from, the code sure knows what it's allocating so it's a good place to just instrument. Having this about:memory page allows us to get much more useful bug reports from users. So maybe you could do the same in KDE, e.g. a menu entry under Help or a button in Help->About. Good luck :)
I've never seen high memory use using radeon, however using remote X apps with an intel card, I managed to hang the machine hard twice after browsing some PDF files.
Regarding comment 47, it is easy to find pixmap use with Ctrl-Esc Detailed memory information, or xrestop.
Using ctrl+esc > Detailed memory Information: Pixmap was max 50 MB. Private goes up > 1 GB, (only) when scrolling too fast. I'm able to reproduce it everytime. When running it in massif, it's too slow to show this issue... So unfortunately, massif doesn't help here. Other ideas?
Description of okular behavior I see with "Normal" setting: - Scrolling in PDF files makes the X server grow very rapidly - This make the X server start swapping - This results in Okular displaying the file very slowly Description of okular behavior I see with "Low memory" setting: - Every page takes around 300 ms to be rendered Ultimately, for me the second setting ("Low memory") results in a much faster scrolling experience for PDF documents. To me it seems that with modern processor performance, the tradeoff between using more memory or more cpu power clearly favors the latter.
I wondered why my Laptop got sooo sloooow... Every action (switching Virtual Desktops, switching tabs in firefox, showing yakuake, showing popup menu...) - then I realised this: $ free -m total used free shared buffers cached Mem: 3800 3151 648 0 45 2083 -/+ buffers/cache: 1023 2776 Swap: 5119 1115 4004 xrestop: 3400000 26 4 1 2515 2556 1017972K 61K 1018034K 19865 LaTeX.pdf �~@~S Okular 1c00000 9 2 1 667 687 652072K 17K 652089K 20390 chapter_formatting.pdf �~@~S Okular top: 19714 root 20 0 3366m 738m 697m S 6,7 19,4 27:03.62 X 24325 franz 20 0 1124m 316m 23m S 5,4 8,3 4:08.02 firefox 19865 franz 20 0 359m 98m 7676 S 0,0 2,6 1:35.55 okular closing every single okular instance will free the memory. Memory usage is set to "normal". I have 4GB of RAM (way more then the 256MB mentioned in the settings), running intel graphics with latest driver. This issue REALLY bugs me. It's a laptop. The HDD needs to write quite much (swapping), so battery will get empty faster - not even talking about performance (->lags...). I need to switch my viewer(s) until this bug is fixed.
Franz, which okular and Qt version are you using?
(In reply to comment #53) > Franz, which okular and Qt version are you using? Currently none. Judging from releases it should have been kde-4.10.2 and Qt-4.8.4. If you want me to confirm this issue I can put it on my list; as soon as I have access to another kde system I'll check this, too.
Yes please it'd be helpful, as of modern Okular and Qt versions we should not be using any X memory unless you are forcing not to use the Qt raster engine (which we don't).
Guys please, we'd welcome if anyone could confirm this still happens in newer versions of okular and Qt.
I just did some testing, using a ~800 pages long document and okular 4.13.0 and xorg-server-1.15.1 on Gentoo amd64. On my desktop, using proprietary Nvidia drivers, I can easily make okular use 5GiB+ of memory (according to htop's "RES" column) by scrolling for a minute. However, the memory seems to be completely released after closing okular, and does not seem to increase Xorg memory usage (as was the case a few years ago). Xrestop only shows 20k of memory used by the process. On my laptop, using open source Intel drivers, scrolling for a minute or two results in high (easily 1GiB) pixmap memory usage in Xrestop (instead of being directly attributed to okular in htop). Again, the memory gets freed after closing okular and does not have any apparent effect on Xorg memory usage. Also, it seems that okular will not eat into swap, but will limit memory usage automatically instead (tested by opening a couple of large documents simultaneously). Note: The above tests were performed using "normal" memory usage setting ("aggressive" gives similar results). Personally, I am happy to see that the allocated memory no longer seems to persist after closing okular (which was my main issue), though I'm not sure how much memory okular should reasonably be allowed to occupy on "normal" memory usage settings. Hope this helps.
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!