Red Hat Bugzilla – Bug 172708
[RHEL4] X doesn't clean up all cursors after calling XFreeCursor
Last modified: 2007-11-30 17:07:21 EST
- Check the memory used by your X server
- Open a bigger pdf in gpdf (> 3 megs) with lots pages
- 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.
Created attachment 120830 [details]
set the cursor several times a second
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
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
So, to me, it looks like it doesn't clean up all frames on animated cursors.
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.