Red Hat Bugzilla – Bug 109626
huge memory leak with xinerama
Last modified: 2007-11-30 17:10:33 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031016
Description of problem:
I have a couple of pci gfx cards around here to play with.
If i set up single monitor XFree with Matrox millenium, all is fine.
If i set up single monitor XFree with ATI Radeon 7500, all is fine.
If i set up dual monitor dual X server with millenium/radeon, all is fine.
If i set up dualmonitor xinerama with dual millenium / dual radeon /
mix, i see a nice and steady growth of the X process size.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. set up xinerama with two cards
3. examine X memory size
4. browse a bit with mozilla
5. examine X memory size (it should be 2-3 times larger than at the start)
6. close mozilla
7. examine X memory size (it does NOT decrease!!)
Expected Results: I'd expect for the X memory size to stay within
certain limits ... I understand a small leak or two here and there,
but this is just too much.
For example, i use xfce4. Right after startup, X size is 25M. After
browsing with mozilla, X size is 80M.
Now i left one konqueror window with a mrtg site refreshing every 5min
up the whole night, only to find the X size 1.3G in the morning. Yay.
Created attachment 95868 [details]
XF86Config for dual millenium
Created attachment 95869 [details]
XFree86 log for dual millenium
Created attachment 95870 [details]
I don't have dual Matrox Millenium 2064 hardware with which to
attempt to reproduce. Can you narrow this problem down to a
simpler configuration, and try to determine what specific
process(es) or behaviour is allegedly increasing memory usage?
This could just be a stray application leaking X resources
perhaps, and not actually be a memory leak in the X server
Dual millenium is just what is right now in my box (waay sharper
picture than radeons ;)
I'd say you can easily reproduce it with any xinerama setup. At least
radeons behave exactly the same here.
Now about that 1.3G ... it really got deallocated when i closed
konqueror, but the new X size was 75M (25M at the start). So there's
still something somewhere being forgotten in memory ... I've narrowed
it this much that it only happens with xinerama (or at least in the
way more obvious way).
Is there some method/procedure to figure out what exactly is taking
space inside the X server?
>I'd say you can easily reproduce it with any xinerama setup. At
>least radeons behave exactly the same here.
For problems of this nature, I don't generally try to reproduce
them until I've been fairly convinced that it is indeed a real
X server or video driver bug, and not some application leaking
pixmaps or other resources. The number of X server memory leak
bugs that get reported that actually turn out to be X server
memory leaks is extremely small. The majority of them are broken
buggy applications leaking resources, and spending hours debugging
something like that to find out it is not an X bug is a rather
large time sink. Before I'd attempt to reproduce this, I would
want direct confirmation from someone that this problem exists
with a specific setup that I can actually set up with hardware
I have available. You have dualhead Radeon, so please set up
dualhead Radeon alone with no Matrox hardware, and test that
configuration alone. Of course we need to rule out the obvious
problems as well first (below)...
>Now about that 1.3G ... it really got deallocated when i closed
>konqueror, but the new X size was 75M (25M at the start).
Then this isn't an X server leak, it is a konqueror X resource
leak, which would be a bug in konqueror. If it only happens in
Xinerama mode, I would assume konqueror has special Xinerama
support that is perhaps buggy. I'm carbon copying our KDE
maintainer Than Ngo for his comments.
>So there's still something somewhere being forgotten in memory ...
>I've narrowed it this much that it only happens with xinerama
>(or at least in the way more obvious way).
That is possible, but it isn't conclusive. That isn't how the
X server works.
>Is there some method/procedure to figure out what exactly is taking
>space inside the X server?
There is the X resource extension and restest binary included. Other
than that, gdb, or preferably gdb-xfree86 from:
Note that people report bugs against the X server a _lot_ which
are rarely ever truely X server bugs in the end, although to the
untrained eye they very much seem to be X server bugs. You'll need
to do further troubleshooting to dig into the problem further
before we can conclude this to be a real X server bug, and we'll
need a simpler test case that is easy to set up, reproduce and
conclusively determine it is an X server bug. If you require
assistance with trying to narrow this down to that level, I
definitely recommend the helpful firstname.lastname@example.org or
email@example.com mailing lists.
Hope this helps.
test case: a mrtg page with 22 graphs
single millenium: X grows by ~5M on each reload
dual millenium: X grows by ~10M on each reload
single radeon: no X growth on reload
dual radeon: same
mga/radeon mix: X grows by ~5M on each reload
viewing a mrtg page with just 4 graphs and reloading it causes just
about 1M increase in X size per head.
conclusion here would be that there is a problem on the line of
konqueror-xfree86-mga. shall i open another bug for this or will Than
Ngo take this on from here?
regarding my initial problem:
test case: same mrtg page, viewed in mozilla
X grows by about the same amount regardless of the gfx setup
for example with dual radeons:
after startxfce4, top reports for X:
My conclusion would be that this is mozilla's fault.
Also, if you have two pci radeons 7500 (RV200 QW) handy, there are
numerous other issues with that setup. X would start properly in only
about 50% cases, other times it would just freeze. When it started, i
could freeze it again with mplayer (-vo x11 AND xv ...) within
seconds, with noticable corruptions on other screen. But these are not
that important for me right now.
If you want more information, please describe briefly how can i obtain
them. I see that running gdb on X would require serial console, but
right now i have just a couple of old vt220 terminals lieing around :)
Try running xrestop from freedesktop.org xapps, which will show you
which applications are using X resources, and how much memory they
consume inside the X server.
Looks like an excellent tool. Just have to get xres running first.
Will report results.
OK, i found the culprit. It's the xfce4 window manager, with over
700mb under pxm mem after about 20 days of running. I'll go bug the
xfce guys :)
Thanks for pointing out this great little tool. It really helps in
situations like this.
I'll report any aditional weirdnes if i see it, for now this bug can
Closing NOTABUG as per above comments.