[Okular-devel] [Bug 177213] High X server memory consumption

[Mark Whitis]

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


Mark Whitis <whitis at freelabs.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |whitis at 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.