Bug 109626 - huge memory leak with xinerama
huge memory leak with xinerama
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: XFree86 (Show other bugs)
1
athlon Linux
medium Severity high
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-11-10 09:11 EST by Jure Pečar
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-12-29 09:00:32 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
XF86Config for dual millenium (4.06 KB, text/plain)
2003-11-10 09:12 EST, Jure Pečar
no flags Details
XFree86 log for dual millenium (51.23 KB, text/plain)
2003-11-10 09:14 EST, Jure Pečar
no flags Details
lspci verbose (3.58 KB, text/plain)
2003-11-10 09:14 EST, Jure Pečar
no flags Details

  None (edit)
Description Jure Pečar 2003-11-10 09:11:27 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):
4.3.0-42

How reproducible:
Always

Steps to Reproduce:
1. set up xinerama with two cards
2. startx
3. examine X memory size 
4. browse a bit with mozilla



Actual Results:  
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.

Additional info:


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.
Comment 1 Jure Pečar 2003-11-10 09:12:49 EST
Created attachment 95868 [details]
XF86Config for dual millenium
Comment 2 Jure Pečar 2003-11-10 09:14:04 EST
Created attachment 95869 [details]
XFree86 log for dual millenium
Comment 3 Jure Pečar 2003-11-10 09:14:36 EST
Created attachment 95870 [details]
lspci verbose
Comment 4 Mike A. Harris 2003-11-10 09:31:00 EST
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.
Comment 5 Jure Pečar 2003-11-10 09:42:25 EST
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?
Comment 6 Mike A. Harris 2003-11-10 11:41:51 EST
>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@xfree86.org or
xfree86@xfree86.org mailing lists.

Hope this helps.
Comment 7 Jure Pečar 2003-11-10 14:22:59 EST
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 :)
Comment 8 Mike A. Harris 2003-12-19 21:54:41 EST
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.
Comment 9 Jure Pečar 2003-12-20 01:45:18 EST
Looks like an excellent tool. Just have to get xres running first.
Will report results.
Comment 10 Jure Pečar 2003-12-21 19:16:16 EST
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.
Comment 11 Mike A. Harris 2003-12-29 09:00:32 EST
Closing NOTABUG as per above comments.

Thanks.

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