https://bugs.kde.org/show_bug.cgi?id=177213
Mark Whitis <whi...@freelabs.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |whi...@freelabs.com --- Comment #14 from Mark Whitis <whitis freelabs com> 2009-05-25 06:50:12 --- > 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. -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. _______________________________________________ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel