Comment 27 for bug 98783

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.