Bug 109626

Created attachment 95868 [details]
XF86Config for dual millenium

Created attachment 95869 [details]
XFree86 log for dual millenium

Created attachment 95870 [details]
lspci verbose

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
itself.

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:

    ftp://people.redhat.com/mharris

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 devel or
xfree86 mailing lists.

Hope this helps.

More info:

regarding konqueror:

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:
size: 158M
RSS:   25M
shared: 2660

+ mozilla:
size: 163M
RSS:   29M
shared: 3068

close mozzila:
size: 161M
RSS:   28M
shared: 2684

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
be closed.

Closing NOTABUG as per above comments.

Thanks.