Bug 172708 - [RHEL4] X doesn't clean up all cursors after calling XFreeCursor
[RHEL4] X doesn't clean up all cursors after calling XFreeCursor
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: xorg-x11 (Show other bugs)
4.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: X/OpenGL Maintenance List
: Desktop
Depends On:
Blocks: 181409
  Show dependency treegraph
 
Reported: 2005-11-08 11:27 EST by Bastien Nocera
Modified: 2007-11-30 17:07 EST (History)
4 users (show)

See Also:
Fixed In Version: RHBA-2006-0412
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-08-10 17:44:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
set the cursor several times a second (545 bytes, text/plain)
2005-11-08 20:02 EST, Ray Strode [halfline]
no flags Details
set the cursor using xlib (406 bytes, text/plain)
2005-11-09 09:48 EST, Matthias Clasen
no flags Details
compile with gcc frob-x-cursor.c -L/usr/X11R6/lib -lX11 -lXRest -o frob-x-cursor (1.73 KB, text/x-csrc)
2005-11-09 12:57 EST, Ray Strode [halfline]
no flags Details
compile with gcc frob-x-cursor.c -o frob-x-cursor -L/usr/X11R6/lib -lX11 -lXRes -DN_RUNS=1000 (2.03 KB, text/x-csrc)
2005-11-09 13:25 EST, Ray Strode [halfline]
no flags Details

  None (edit)
Description Bastien Nocera 2005-11-08 11:27:02 EST
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
Comment 1 Ray Strode [halfline] 2005-11-08 20:02:12 EST
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.
Comment 3 Matthias Clasen 2005-11-09 09:46:38 EST
X problem, I'd say. Here is a pure Xlib program which shows the same behaviour.
Comment 4 Matthias Clasen 2005-11-09 09:48:01 EST
Created attachment 120841 [details]
set the cursor using xlib
Comment 5 Ray Strode [halfline] 2005-11-09 12:55:40 EST
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.
Comment 6 Ray Strode [halfline] 2005-11-09 12:57:10 EST
Created attachment 120848 [details]
compile with gcc frob-x-cursor.c -L/usr/X11R6/lib -lX11 -lXRest  -o frob-x-cursor
Comment 7 Ray Strode [halfline] 2005-11-09 13:25:37 EST
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.
Comment 8 Ray Strode [halfline] 2005-11-10 10:59:31 EST
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.
Comment 11 Mike A. Harris 2006-03-28 13:02:14 EST
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
Comment 13 Bastien Nocera 2006-03-30 04:20:43 EST
Packages tested successfully, thanks.
Comment 17 Mike A. Harris 2006-04-25 10:20:27 EDT
Setting to MODIFIED state.
Comment 20 Red Hat Bugzilla 2006-08-10 17:44:40 EDT
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

Note You need to log in before you can comment on or make changes to this bug.