Bug 127681 - xorg x11 has memory leak
Summary: xorg x11 has memory leak
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11   
(Show other bugs)
Version: 2
Hardware: i386 Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-07-12 15:11 UTC by Bryan Christ
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-07-28 17:47:44 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
screen shot of gnome-system-monitor (78.07 KB, image/png)
2004-07-12 15:12 UTC, Bryan Christ
no flags Details
cat /proc/$(pidof X)/maps as root (12.11 KB, text/plain)
2004-07-12 20:20 UTC, Mike A. Harris
no flags Details

Description Bryan Christ 2004-07-12 15:11:03 UTC
Description of problem:
After about a week of operation, X consumes nearly 300MB of memory. 
Two weeks of usage will consumer upwards of 500MB of memory causing
lots of swapping on my system which only has 512MB of RAM.

Version-Release number of selected component (if applicable):
I am currently experiencing this problem on xorg-x11-6.7.0-5 but saw
the same problem with the previous release which was delivered with
the initial Fedora Core 2 Final images.

How reproducible:
Run xorg-x11 for a week and monitor the memory usage.  Consumption
should continue to increase over time.

Steps to Reproduce:
Actual results:

Expected results:

Additional info:
Originally I was using the NVidia GLX binary driver 1.0-5336.  I am
now testing with the 1.0-6106 release.  However, I expect the same

Gnome is the primary UI and gtk is pakcage version gtk2-2.4.0-1.

This system is frequenly updated using yum pulling from the fedora and
dag repositories.

Comment 1 Bryan Christ 2004-07-12 15:12:21 UTC
Created attachment 101812 [details]
screen shot of gnome-system-monitor

Attached is a screen shot showing the memory consuption after apporximately 1

Comment 2 Mike A. Harris 2004-07-12 17:16:05 UTC
The majority of "X is memory leaking" bug reports that we receive
generally turn out to be an X client application leaking X resources,
and are not a memory leak in the X server itself.  Mozilla, nautilus,
gnome-panel, various gnome panel applets have been candidates in the
past which have allocated X server resources and then leaked them.

X server resources are stored in the X server itself, so the net
result is that the X server's memory usage increases over time, even
though it is not a bug in the X server.  This is similar to an
application allocating memory from the kernel and leaking it - it
is the application which is buggy, rather than the kernel.

Unfortunately, this type of problem is often difficult to reproduce,
and about 99% of the time it turns out to be an application that is
at fault rather than the X server.  XFree86 4.3.0 and X.Org X11
6.7.0 have a new extension called the "X Resource Extension" which
can be used to examine what resources are being used in the X server
by what clients.

We include a top-like application called "xrestop" in Fedora Core 2
which can be used to determine what application is leaking X
resources which you may find useful in trying to determine what if
any of your applications and desktop components might be leaking

Another point to note, is that applications like "top" and "ps" do
not properly show the true amount of memory used by the X server.
The memory shown by these applications also includes all memory
mapped devices such as framebuffer memory and MMIO ranges.  If you've
got a 128Mb video card for example, the X server's memory usage
will show up in top as being 128Mb larger than what is really used.

The output of "cat /proc/$(pidof X)/maps" can be used to determine
how much memory the X server is truly using, however it requires
detailed understanding of the layout of the maps file to get the
true numbers.

Red Hat does not support systems which are running proprietary
or 3rd party video drivers, including the Nvidia driver.  Please
uninstall the Nvidia proprietary driver, and reinstall the
xorg-x11 package that came with the OS, as Nvidia replaces various
X server modules and core system libraries with their own.  Once
you've restored the drivers that ship with the OS, you can
reconfigure the X server to use the "nv" driver, and then monitor
your system over time.  Use the "xrestop" utility when you suspect
the X server is leaking memory, and there's a good chance you'll
see some app is utilizing a lot of X server resources.

Killing mozilla, nautilus or whatever the application is will
usually free up a lot of this memory, however for optimization
purposes the X server holds on to some of it depending on various

Once you've had a chance to test out the above, please report back
with your findings, and we can go from there.

Thanks in advance.

Comment 3 Bryan Christ 2004-07-12 19:29:59 UTC
Okay.  I have installed xrestop and will leave it running over a long
duration (a week or so) and see if I spot any culprits.  When I first
noticed the issue several weeks ago, I was at almost 500MB so I closed
all of the applications, logged out (back to GDM) and then logged back
in.  Some of the memory was released but I was still at about 230MB
which was clearly too high.  Shortly after I wrote up this issue, I
filed another bugzilla--127682.  Based on what you describe here, do
you think these two could be related?

Comment 4 Mike A. Harris 2004-07-12 20:20:10 UTC
Could very well be related.  In general, the larger desktop apps tend
to leak memory sometimes.  Some of the leaks are smaller and thus go
unnoticed for longer periods of time.  Others are much larger leaks
and are aparent within minutes/hours/days.  Likewise apps can leak
X resources in a similar manner, the only difference being that the
app doesn't get bigger, but the X server does.

230Mb shown by top for the X server is actually rather small, as
most of that is video memory and MMIO register mappings, etc.

Here is my X server, which has been running for probably 2 weeks or

3299 root      15   0  204M  44M 18568 S     8.2  4.4  1364m   0 X

The 204Mb you see there, is not 204Mb of physical memory being
stolen from other application's potential usage though.  128Mb
of it is my FireGL 8800's video memory.  I'll attach some details.

Comment 5 Mike A. Harris 2004-07-12 20:20:44 UTC
Created attachment 101825 [details]
cat /proc/$(pidof X)/maps   as root

Comment 6 Mike A. Harris 2004-07-12 20:29:22 UTC
000a0000-000c0000 rwxs 000a0000 21:02 65557      /dev/mem

000f0000-00100000 rwxs 000f0000 21:02 65557      /dev/mem

Video framebuffer (memory) 128Mb
b720b000-bf20b000 rw-s e0000000 21:02 65557      /dev/mem

Video BIOS:
bf20b000-bf28b000 rw-s fe5f0000 21:02 65557      /dev/mem
bf28b000-bf30b000 rw-s fe5f0000 21:02 65557      /dev/mem
bf30b000-bf38b000 rw-s fe5f0000 21:02 65557      /dev/mem
bf38b000-bf40b000 rw-s fe5f0000 21:02 65557      /dev/mem
bf42b000-bf4ab000 rw-s fe5f0000 21:02 65557      /dev/mem

01:00.0 Class 0300: 1002:5148 (rev 80)
        Subsystem: 1002:0152
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping+ SERR+ FastB2B-
        Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 64 (2000ns min), cache line size 08
        Interrupt: pin A routed to IRQ 17
        Region 0: Memory at e0000000 (32-bit, prefetchable) [size=256M]
        Region 1: I/O ports at c800 [size=256]
        Region 2: Memory at fe5f0000 (32-bit, non-prefetchable) [size=64K]
        Expansion ROM at fe5c0000


When you subtract all of the above plus other stuff I didn't
comment on, what's left is a very small amount of memory being
used, and most of that is storing pixmaps.  Today's graphical
desktop is quite heavy on graphics and images, in particular
web browsing.  This stores a lot of images inside the X server,
which is intentional, and will cause the X server's memory footprint
to increase over time.

Hope this helps clarify Xresource usage a bit.


Comment 7 Mike A. Harris 2004-07-28 17:47:44 UTC
Closing issue as "NOTABUG" as it is more likely to be an application
bug than an X server bug.

If a particular application included with the OS can be shown to be
causing this problem, please reopen the bug report and reassign it to
the component of the resource leaking application.

If the problem only occurs with Nvidia's proprietary drivers,it is
most likely a bug in the driver itself, and should be reported
directly to Nvidia in that case.

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