ubuntu-x-swat team mailing list archive

[whitis <whitis@xxxxxxxxxxxx>]

This problem is reminiscent of similar problems with shmget().   You
could either create a private shared memory segment, in which case you
could only share it with subprocesses, or you created a public one.   If
you created a public one, it was not automatically deleted when your
process exited or when the last process sharing the segment exited.   At
least there, you could run a utility program to clean up.

Sure enough, the semantics of XShmCreatePixmap and XShmCreatePixmap look similar, but less documented regarding cleanup and with no utility.
http://www.xfree86.org/current/mit-shm.html
However, these shared memory segments are allocated using shmget().

I checked, and okular's Xshm does not show up in ipcs.

KSharedPixmaps "exist only on the server", implying the server creates them, not the client.   And no shmget() would be expected to be used because applications share a common X server.
http://api.kde.org/2.2-api/classref/kdeui/KSharedPixmap.html
http://developer.kde.org/documentation/library/3.1-api/kdeui/html/ksharedpixmap_8cpp-source.html

It uses XInternAtom and  XConvertSelection
It appears to create a selection named KDESHPIXMAP:xxxxxx
xlsatoms doesn't show any such atom names.

OpenGL may have its own pixmap sharing mechanisms.

I still suspect this is a shared pixmap issue, though I haven't found
the specific shared pixmap mechanism in use.

I see this as the intersection of a number of bugs:
   - X or OpenGL failure to implement reference counting, close on last client exit semantics or incorrect implementation.
   - X or OpenGL failure to provide utilities to list and destroy orphaned shared pixmaps
   - xrestop failure to account for shared pixmaps
   - Okular - improper freeing of shared resources
   - X server/utils failure to identify application which created each retained resource.
Looks like yet another case of bugs compounded by other bugs.   If even one module had been implemented correctly, the problem either would not occur or there would at least be a workaround that would help you clean up the mess or identify the culpret.

I do think I have collected enough information that this can be
reproduced (with low but practical probability) and that it can be
escalated upstream to nvidia AND okular.   Even if the problem can't be
reproduced on a particular machine, it appears that it is related to
okular shared pixmap storage on the server and that can be analyzed.

Okular probably isn't the only app which has this problem, but it is one
that is known to have this problem.   And it is not just an Okular bug
since the X server allows applications to create messes that outlive the
application and doesn't provide a way for the user to identify the
application causing the problem and to clean up the mess.

-- 
MASTER: memory leak
https://bugs.launchpad.net/bugs/98783
You received this bug notification because you are a member of Ubuntu-X,
which is subscribed to xorg-server in ubuntu.