gpdf 2.8.2-4.4 Reproducer: - Check the memory used by your X server - Open a bigger pdf in gpdf (> 3 megs) with lots pages[1] - Press "Page down" keyboard button and keep it pressed until you reach the end of the document. - Press "Page up" until you reach the top. - Repeat several times - Close gpdf - Check the memory used by your X server, it should have increased by a couple of megabytes (depending how many times you browsed through the file) I have also tested with the upstream gpdf 2.8.3 without reproducing the problem, and our 2.8.2-4.4 package without gpdf-2.8.2-CAN-2005-2097.patch without reproducing the problem. [1]: http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/pdf/rhl-ig-x86-en-9.pdf for example
Created attachment 120830 [details] set the cursor several times a second Hi, This looks like it might actually be a gtk+ or X bug. I think a cursor is being leaked every time gpdf changes to its busy cursor (which happens a lot of times when loading a document and then each time you press page down or page up). It's fairly easily reproducible with a small test program like the one attached above. xrestop --batch | grep -A 15 foo shows the number of cursors on the X server increasing.
X problem, I'd say. Here is a pure Xlib program which shows the same behaviour.
Created attachment 120841 [details] set the cursor using xlib
Yea, this definitely looks like an X bug. I'll attach a test case that returns 0 if it doesn't leak, and the number of leaked cursors when it does leak.
Created attachment 120848 [details] compile with gcc frob-x-cursor.c -L/usr/X11R6/lib -lX11 -lXRest -o frob-x-cursor
Created attachment 120849 [details] compile with gcc frob-x-cursor.c -o frob-x-cursor -L/usr/X11R6/lib -lX11 -lXRes -DN_RUNS=1000 Matthias pointed out that the test case may be less than convincing because it's reasonable for the X server to cache common cursors. To show this isn't happening, I've modified the test case to loop 1000 times and return the average number of leaked cursors per iteration.
A couple more notes... With the Bluecurve cursor theme, the busy cursor (which is animated) seems to leak 12 cursors, but the arrow (which is not animated) seems to not leak any. If I delete my cursor themes then the default non-animated watch busy cusor doesn't leak. So, to me, it looks like it doesn't clean up all frames on animated cursors.
https://bugs.freedesktop.org/show_bug.cgi?id=1043 http://cvs.freedesktop.org/xorg/lib/Xcursor/src/cursor.c?r1=1.3&r2=1.4&makepatch=1&diff_format=h
Patch xorg-x11-6.8.2-xcursor-memleak-fix.patch added to test candidate for U4. Please test the xorg-x11-6.8.2-1.EL.13.26 packages available for download via FTP at: ftp://people.redhat.com/mharris/testing/4E/xorg-x11
Packages tested successfully, thanks.
Setting to MODIFIED state.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2006-0412.html