Bug 58987

Could you please attach to the bug report a copy of your X configuration
file, your X server log, /var/log/messages all as separate uncompressed
file attachments using the link below.

Also please include the output of the following commands:
uname -a
rpm -qa | sort > filelist.txt          (attach filelist.txt as an attachment)
lspci -v
lspci -n

Thanks.

Created attachment 44036 [details]
rpm -qa | sort

Created attachment 44037 [details]
/var/log/messages

Created attachment 44038 [details]
/etc/X11/XF86Config-4

Created attachment 44039 [details]
/var/log/XFree86.0.log

Here are the other outputs

-------------------------------------

[root@yesthatguy root]$ uname -a
Linux yesthatguy.internal.gambitdesign.com 2.4.9-21 #1 Thu Jan 17 14:16:30 EST 2002 i686 unknown

-------------------------------------

[root@yesthatguy root]# lspci -v
00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 02)
        Flags: bus master, medium devsel, latency 64
        Memory at e4000000 (32-bit, prefetchable) [size=64M]
        Capabilities: [a0] AGP version 1.0

00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev 02) (prog-if 00 [Normal decode])
        Flags: bus master, 66Mhz, medium devsel, latency 64
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
        Memory behind bridge: e0000000-e1dfffff
        Prefetchable memory behind bridge: e1f00000-e3ffffff

00:04.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02)
        Flags: bus master, medium devsel, latency 0

00:04.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) (prog-if 80 [Master])
        Flags: bus master, medium devsel, latency 32
        I/O ports at d800 [size=16]

00:04.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01) (prog-if 00 [UHCI])
        Flags: bus master, medium devsel, latency 32, IRQ 5
        I/O ports at d400 [size=32]

00:04.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02)
        Flags: medium devsel, IRQ 9

00:09.0 Ethernet controller: Bridgecom, Inc: Unknown device 0985 (rev 11)
        Subsystem: Bridgecom, Inc: Unknown device 0574
        Flags: bus master, medium devsel, latency 32, IRQ 5
        I/O ports at d000 [size=256]
        Memory at df800000 (32-bit, non-prefetchable) [size=1K]
        Expansion ROM at <unassigned> [disabled] [size=128K]
        Capabilities: [c0] Power Management version 2

00:0b.0 Multimedia audio controller: Creative Labs SB Live! EMU10000 (rev 03)
        Subsystem: Creative Labs CT4620 SBLive!
        Flags: bus master, medium devsel, latency 32, IRQ 10
        I/O ports at b800 [size=32]
        Capabilities: [dc] Power Management version 1

00:0b.1 Input device controller: Creative Labs SB Live! (rev 01)
        Subsystem: Creative Labs Gameport Joystick
        Flags: bus master, medium devsel, latency 32
        I/O ports at b400 [size=8]
        Capabilities: [dc] Power Management version 1

00:0c.0 Multimedia controller: Sigma Designs, Inc. REALmagic Hollywood Plus DVD
Decoder (rev 01)
        Flags: bus master, medium devsel, latency 32, IRQ 11
        Memory at df000000 (32-bit, non-prefetchable) [size=1M]

01:00.0 VGA compatible controller: nVidia Corporation Riva TnT2 [NV5] (rev 11) (prog-if 00 [VGA])
        Subsystem: Diamond Multimedia Systems Viper V770
        Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 11
        Memory at e0000000 (32-bit, non-prefetchable) [size=16M]
        Memory at e2000000 (32-bit, prefetchable) [size=32M]
        Expansion ROM at e1ff0000 [disabled] [size=64K]
        Capabilities: [60] Power Management version 1
        Capabilities: [44] AGP version 2.0

-------------------------------------

[root@yesthatguy root]# lspci -n
00:00.0 Class 0600: 8086:7190 (rev 02)
00:01.0 Class 0604: 8086:7191 (rev 02)
00:04.0 Class 0601: 8086:7110 (rev 02)
00:04.1 Class 0101: 8086:7111 (rev 01)
00:04.2 Class 0c03: 8086:7112 (rev 01)
00:04.3 Class 0680: 8086:7113 (rev 02)
00:09.0 Class 0200: 1317:0985 (rev 11)
00:0b.0 Class 0401: 1102:0002 (rev 03)
00:0b.1 Class 0980: 1102:7002 (rev 01)
00:0c.0 Class 0480: 1105:8300 (rev 01)
01:00.0 Class 0300: 10de:0028 (rev 11)

Ok, I looked at your supplied information and think I found something.
For troubleshooting purposes, can you please try disabling the
screensaver in KDE for a few days, and see if the problem goes away.
If it does, then I believe the KDE screensaver might be memory leaking,
perhaps allocating resources in the X server, which are never freed, etc.

Please update the report in a few days or so with the status of your
testing, and I've got some other tests in mind also.

I've disabled the KDE screensaver, and also wallpaper, and it initially looks like X is still eating up memory.  I'll let it run its course overnight tonight, and 
see if there's anything new or changed in the logs.

After disabling the screensaver and wallpaper, X is still chewing up memory.  I will attach a messages log from the most recent crash here.  Let me know 
what else you'd like me to try.

Created attachment 44336 [details]
/var/log/messages (2002/02/01)

Continued use is having much the same result.  A couple times, the system has recovered to a shell after the X crash now, rather than freezing up the 
terminal.  If there's any other information you need, or other things to try, please let me know.

Just so I can get some idea - what is considered a normal range of memory usage for X?

Again, if X ends up increasing in memory size, this does not at all
indicate that XFree86 is necessarily memory leaking.  XFree86 offers
resources to applications, and an application can end up leaking X
resources.  For example, an application which allocates a window, or
a graphic image in the X server, ends up increasing the memory usage
of the X server.  if that application then continues to allocate new
X resources, and not ever free up the ones it used previously when it
is done with them, then the X server's memory usage will continue to
rise, at no fault of the X server.  So, the problem could be anywhere,
either an application, or the Xserver, or one of the libraries in use.

Your log files don't show anything out of the ordinary to me per se.

If something is in fact memleaking, there is not much we can do about
it without knowing what exactly is memory leaking, or without specific
step by step instructions on how to reproduce the problem.

I recommend disabling software one piece at a time, to try and get a
reproduceable test case.

Some other possible troubleshooting steps, are to use switchdesk to
change your desktop to GNOME, and see if the problem disappears under
GNOME.  Another possibility is to put a different brand/model of video
card in the machine and try your current setup with that.

Set up a cron job which runs every 5 minutes and sends you a detailed
report of ps output showing all processes memory usage over time.

Some of those might help find the problem.  Unfortunately, we cant fix
an unknown memory leak... we need to know what the memory leak is in
in order to debug the software.

Hope this helps.

Switching from KDE to Gnome seemed to eliminate the problem altogether, although I'd like to be able to use KDE.  I'm looking through now trying to 
find more things to disable within KDE.  Please let me know if you have any suggestions for spots to look at.

I have been tearing my hair out with the same problem on a RedHat 7.2 system for
months.  Also using Nvidia Riva TNT2.  It does not matter whether I use the
stock XFree86 4.1.0 drivers or ther closed source NVIDIA drivers.  Memory leaks
until oom killing starts.  I originally had it pegged to the VM changes in the
kernel.  I have tried stock RedHat kernels, kernels compiled from RedHat sources
and most of the 2.4.9+ development kernels to no avail.  After up2dating the
machine to the latest of everything last night, I find that I still run out of
memory.

I have 256 MB and have upped swap to over 1 Gig for VM testing with the
2.4.x/testing kernels. (currently 2.4.18-rc4).

In short I request that RedHat release XFree86 4.2.0 for RH 7.2.  since it seems
that the good folks over at SUSE have pegged the problem down to a bug within
XFree86 4.1.0 with certain drivers.

The bug is triggered under KDE buy activating antialiasing of fonts.  SUSE's
quick and dirty work around is to deactivate antialiasing.  Or for the brave at
heart, upgrade to XFree 4.2.0.

Check the SUSE knowlege base at:
http://sdb.suse.de/en/sdb/html/pohletz_x11_consuming_mem.html

I am dismayed to find that the only redhat packaged version of the XFree86 4.2.0
sources (from rawhide) seems not to be GPG signed.

I really wish RedHa would package up a release of 4.2.0 for Redhat 7.2.

No rawhide packages are _ever_ signed, because they are not official
packages.  They are Red Hat internal development RPM's in constant
state of flux.

XFree86 4.2.0 may be released at some point for RHL 7.x howeve there
is no plan to do so currently at this time.  XFree86 4.2.0 contains many
bugs yet which require fixing before we can release an official update.

If there are driver patches available that fix this problem I can
investigate adding fixes to our next erratum release however and possibly
make an unofficial build available on my ftp space for testing.

XFree86 4.2.0 is available on my ftp space for the time being, and is
compiled for RHL 7.x:  ftp://people.redhat.com/mharris/testing/bleeding-edge

The problem has been confirmed by a few people to not be present in 4.2.0,
so I'm closing the bug as fixed in rawhide now.  You can try the rawhide
packages out if you like from the above URL.  You'll need the rawhide
kernel, and you may need other packages such as freetype, etc. as well.
Keep in mind, using these 4.2.0 packages is only an unsupported workaround,
and may require updating more software than you're comfortable with doing,
since they are not official packages.  They are also as I stated in my
last comment not signed.