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: 1. 2. 3. 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 results. 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.
Created attachment 101812 [details] screen shot of gnome-system-monitor Attached is a screen shot showing the memory consuption after apporximately 1 week.
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 resources. 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 factors. 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.
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?
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 so: 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.
Created attachment 101825 [details] cat /proc/$(pidof X)/maps as root
VGA: 000a0000-000c0000 rwxs 000a0000 21:02 65557 /dev/mem BIOS: 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. TTYL
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.