Bug 58987 - unknown memory leak causes out of memory errors
unknown memory leak causes out of memory errors
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
7.2
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-01-28 17:45 EST by Brian Salomaki
Modified: 2007-04-18 12:39 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-02-26 16:41:27 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
rpm -qa | sort (20.26 KB, text/plain)
2002-01-30 16:18 EST, Brian Salomaki
no flags Details
/var/log/messages (72.16 KB, text/plain)
2002-01-30 16:18 EST, Brian Salomaki
no flags Details
/etc/X11/XF86Config-4 (1.76 KB, text/plain)
2002-01-30 16:19 EST, Brian Salomaki
no flags Details
/var/log/XFree86.0.log (21.37 KB, text/plain)
2002-01-30 16:20 EST, Brian Salomaki
no flags Details
/var/log/messages (2002/02/01) (91.71 KB, text/plain)
2002-02-01 22:07 EST, Brian Salomaki
no flags Details

  None (edit)
Description Brian Salomaki 2002-01-28 17:45:36 EST
Description of Problem:

I am running on a relatively fresh install of RedHat 7.2.  I applied all of the updates at one time, so I'm not absolutely sure that this is an X problem and 
not a kernel or other problem, but it at least deals with X.  I had upgraded to the latest update of X (4.1.0-15) as part of this initial mass upgrade, so I 
initially suspected that as the problem.  I have since downgraded to the release version (4.1.0-3), but I am still having the same problem.  I first noticed 
that if I left my computer running overnight, by the time I came back in the morning, X wouldn't be responding.  I was still however able to SSH in from 
another machine and do a full shutdown -r fine.  Looking in /var/messages, I am getting Out of Memory errors, presumably at the time everything dies.  At 
the moment, I am watching X's memory usage in top, and it is constantly rising (currently at 333MB).

I have 384MB of physical RAM, and 1GB of swap space right now.  I've had other installs work just fine, so I'm not sure what the problem is or where to 
look.

Version-Release number of selected component (if applicable):

4.1.0-3, 4.1.0-15

How Reproducible:

Always

Steps to Reproduce:
1. Start X
2. Wait

Actual Results:

X started to eat up memory, constantly increasing.

Expected Results:

X should not have used up so much memory.

Additional Information:
 
Video card: NVIDIA RIVA TNT2 (I've tried using both the included "nv" driver and the company's "nvidia" driver - same results).
PII 400MHz
384 MB RAM, 1GB swap
Currently using kernel 2.4.9-21 RPM upgrade from RedHat.
Running KDE 2.2.2 RPMs from RedHat.

Open in X during the crash: kmail, xmms, gaim

Here is the snippet from the logs from the last crash.

Jan 27 22:52:42 yesthatguy kernel: Out of Memory: Killed process 7544 (kmatrix.kss).
Jan 27 22:52:42 yesthatguy kernel: Out of Memory: Killed process 5027 (xmms).
Jan 27 22:52:42 yesthatguy kernel: Out of Memory: Killed process 5028 (xmms).
Jan 27 22:52:42 yesthatguy kernel: Out of Memory: Killed process 5029 (xmms).
Jan 27 22:52:42 yesthatguy kernel: Out of Memory: Killed process 5030 (xmms).
Jan 27 22:56:47 yesthatguy kernel: Out of Memory: Killed process 1069 (httpd).
Jan 27 22:57:18 yesthatguy kernel: Out of Memory: Killed process 1070 (httpd).
Jan 27 22:57:21 yesthatguy kernel: Out of Memory: Killed process 1071 (httpd).
Jan 27 22:57:22 yesthatguy kernel: Out of Memory: Killed process 1072 (httpd).
Jan 27 22:57:49 yesthatguy kernel: Out of Memory: Killed process 1073 (httpd).
Jan 27 22:57:54 yesthatguy kernel: Out of Memory: Killed process 1074 (httpd).
Jan 27 22:58:46 yesthatguy kernel: Out of Memory: Killed process 1075 (httpd).
Jan 27 22:58:50 yesthatguy kernel: Out of Memory: Killed process 1076 (httpd).
Jan 27 22:59:23 yesthatguy kernel: Out of Memory: Killed process 2115 (kdeinit).Jan 27 23:00:16 yesthatguy kernel: Out of Memory: Killed process 
2099 (kdeinit).Jan 27 23:00:35 yesthatguy kernel: Out of Memory: Killed process 2117 (kdeinit).Jan 27 23:01:19 yesthatguy kernel: Out of Memory: 
Killed process 2499 (kdeinit).Jan 27 23:01:23 yesthatguy kernel: Out of Memory: Killed process 2483 (kdeinit).Jan 27 23:03:54 yesthatguy kernel: Out of 
Memory: Killed process 8785 (httpd).
Jan 27 23:03:54 yesthatguy kernel: Out of Memory: Killed process 8786 (httpd).
Jan 27 23:04:43 yesthatguy kernel: Out of Memory: Killed process 8787 (httpd).
Jan 27 23:04:44 yesthatguy kernel: Out of Memory: Killed process 8790 (httpd).
Jan 27 23:04:52 yesthatguy kernel: Out of Memory: Killed process 8791 (httpd).
Jan 27 23:05:05 yesthatguy kernel: Out of Memory: Killed process 2124 (kdeinit).Jan 27 23:05:17 yesthatguy kernel: Out of Memory: Killed process 
2126 (kdeinit).Jan 27 23:05:58 yesthatguy kernel: Out of Memory: Killed process 2149 (kdeinit).Jan 27 23:05:58 yesthatguy kernel: Out of Memory: 
Killed process 2478 (kdeinit).Jan 27 23:06:51 yesthatguy kernel: Out of Memory: Killed process 2096 (kdeinit).Jan 27 23:06:55 yesthatguy kernel: Out of 
Memory: Killed process 2127 (alarmd).
Jan 27 23:07:59 yesthatguy kernel: Out of Memory: Killed process 2090 (kdeinit).Jan 27 23:08:10 yesthatguy kernel: Out of Memory: Killed process 
2093 (kdeinit).Jan 27 23:08:10 yesthatguy kernel: Out of Memory: Killed process 2541 (gpilotd).Jan 27 23:08:30 yesthatguy kernel: Out of Memory: 
Killed process 2116 (ksmserver).
Jan 27 23:09:02 yesthatguy gnome-name-server[2537]: input condition is: 0x11, exiting
Comment 1 Mike A. Harris 2002-01-30 10:05:29 EST
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.

Comment 2 Brian Salomaki 2002-01-30 16:18:00 EST
Created attachment 44036 [details]
rpm -qa | sort
Comment 3 Brian Salomaki 2002-01-30 16:18:48 EST
Created attachment 44037 [details]
/var/log/messages
Comment 4 Brian Salomaki 2002-01-30 16:19:16 EST
Created attachment 44038 [details]
/etc/X11/XF86Config-4
Comment 5 Brian Salomaki 2002-01-30 16:20:34 EST
Created attachment 44039 [details]
/var/log/XFree86.0.log
Comment 6 Brian Salomaki 2002-01-30 16:25:05 EST
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)
Comment 7 Mike A. Harris 2002-01-31 01:19:32 EST
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.
Comment 8 Brian Salomaki 2002-01-31 17:32:15 EST
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.
Comment 9 Brian Salomaki 2002-02-01 22:06:03 EST
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.
Comment 10 Brian Salomaki 2002-02-01 22:07:19 EST
Created attachment 44336 [details]
/var/log/messages (2002/02/01)
Comment 11 Brian Salomaki 2002-02-07 17:14:19 EST
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?
Comment 12 Mike A. Harris 2002-02-11 02:06:08 EST
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.
Comment 13 Brian Salomaki 2002-02-17 15:40:55 EST
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.
Comment 14 Bennett Feitell 2002-02-26 16:14:44 EST
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.
Comment 15 Mike A. Harris 2002-02-26 16:41:22 EST
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.
Comment 16 Mike A. Harris 2002-03-14 02:43:09 EST
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.

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