Bug#281050: xserver-common: [i810] Memory leak
retitle 281050 xserver-xfree86: [i810] memory leak provoked by animated cursors used with gdk_cursor_unref() tag 281050 + upstream forwarded 281050 https://bugs.freedesktop.org/show_bug.cgi?id=1043 thanks On Thu, Jan 20, 2005 at 01:00:02PM +0200, Modestas Vainius wrote: > Related bugs in other locations (neither of which is marked as fixed): > > https://bugs.freedesktop.org/show_bug.cgi?id=1043 > http://bugs.gentoo.org/show_bug.cgi?id=31982 > > [1]. http://www.kde-look.org/content/show.php?content=18214 > [2]. http://mif.vu.lt/~mova3971/xf/watch > [3]. http://mif.vu.lt/~mova3971/xf/memleak.c > [4]. http://mif.vu.lt/~mova3971/xf/gpdf -- G. Branden Robinson|Of two competing theories or Debian GNU/Linux |explanations, all other things [EMAIL PROTECTED] |being equal, the simpler one is to http://people.debian.org/~branden/ |be preferred. -- Occam's Razor signature.asc Description: Digital signature
Processed: Re: Bug#281050: xserver-common: [i810] Memory leak
Processing commands for [EMAIL PROTECTED]: > retitle 281050 xserver-xfree86: [i810] memory leak provoked by animated > cursors used with gdk_cursor_unref() Bug#281050: xserver-xfree86: server has memory leaks Changed Bug title. > tag 281050 + upstream Bug#281050: xserver-xfree86: [i810] memory leak provoked by animated cursors used with gdk_cursor_unref() Tags were: moreinfo Tags added: upstream > forwarded 281050 https://bugs.freedesktop.org/show_bug.cgi?id=1043 Bug#281050: xserver-xfree86: [i810] memory leak provoked by animated cursors used with gdk_cursor_unref() Noted your statement that Bug has been forwarded to https://bugs.freedesktop.org/show_bug.cgi?id=1043. > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#281050: xserver-common: [i810] Memory leak
Hello, > X footprint keeps growing because of repeatable memory allocations for the > cursor > and gdk_cursor_unref() failures to free that memory. However, this doesn't > happen > with all types of cursors. Only *animated* ones are affected (I base > this hypothesis on my tests). Indeed, I switched to an unanimated cursor theme as a workaround, and the problem seems to have gone away. I owe you one! -- Gintautas Miliauskas signature.asc Description: =?iso-8859-2?Q?=A9i?= =?iso-8859-2?Q?_lai=B9ko?= dalis yra =?iso-8859-2?Q?pasira=B9yta?= skaitmeniniu =?iso-8859-4?Q?b=FEdu?=
Bug#281050: xserver-common: [i810] Memory leak
On Thu, Jan 20, 2005 at 01:00:02PM +0200, Modestas Vainius wrote: > After a few hours of investigation I've tracked down this bug. At > least I've discovered what code causes Xserver to leak memory, when > the bug is "exploited" by gpdf. It's as simple as the following: Nice work. It explains why I discovered the problem so often by running Firefox, since Firefox will change to the (animated) wait-cursor lots of times. > I've made a simple gtk program, which starts executing the code above > infinite number times once you press the "Test memleak!" button (thus > you will need to use CTRL+C or `kill` to terminate the program). Here > it's the step-by-step guide to reproduce the memleak: Yup, running for 30 seconds its enough to bring my system to swapping, and pmap shows: [EMAIL PROTECTED] ~]# pmap -x $(pidof X) [...] 0a512000 360896 - - - rw---[ anon ] [...] With that I guess that bugs should be fixed soon, thanks again. Regards, Matthias pgpQXcxNaGdwd.pgp Description: PGP signature
Bug#281050: xserver-common: [i810] Memory leak
Hello,
After a few hours of investigation I've tracked down this bug. At least I've
discovered what code causes Xserver to leak memory, when the bug is
"exploited" by gpdf. It's as simple as the following:
cursor = gdk_cursor_new_for_display(display, GDK_WATCH);
// ... //
gdk_cursor_unref(cursor);
This code gets repeated approx. twice as many times as there are pages in the
pdf (when processing both bookmarks and thumbnails). While this is the bug in
the gpdf itself (the cursor should not be set so many times), it reveals
the bug in the X server. X footprint keeps growing because of repeatable
memory allocations for the cursor and gdk_cursor_unref() failures to free that
memory. However, this doesn't happen with all types of cursors. Only
*animated* ones are affected (I base this hypothesis on my tests). Memory
occupied by static cursors gets freed properly by the gdk_cursor_unref()
routine. This explains why other people are not suffering from this bug.
I've made a simple gtk program, which starts executing the code above infinite
number times once you press the "Test memleak!" button (thus you will need to
use CTRL+C or `kill` to terminate the program). Here it's the step-by-step
guide to reproduce the memleak:
1. Make sure your "watch" cursor is the animated one or change the argument 2
of the gdk_cursor_new_for_display() accordingly to the cursor which is
animated in the theme you're using. If neither is animated, you can obtain one
from [1] or other source. I extracted the "watch" cursor from this theme and
put it on my web site[2]. Simply place it into ~/.icons//cursors/watch This should be
enough to reproduce the bug without restarting X.
2. Compile memleak.c from [3] with the following command (you will need
libgtk2.0-dev and its dependences for this):
gcc memleak.c -o memleak -I/usr/include/gtk-2.0 -I/usr/include/glib-2.0
-I/usr/lib/gtk-2.0/include -I/usr/lib/glib-2.0/include
-I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -L/usr/lib -lgtk-x11-2.0
and start the program.
3. Press the "Test memleak!" button in the GUI and observe X server memory
usage ("RES" field with `top`). If you have a fast pc, X should consume
hundreds MBs of memory *very* quickly.
4. To kill the program use CTRL+C or `kill` (it's my first gtk program ever,
so I haven't invested more time in making termination more sophisticated)
Another interesting thing is that X seems to reuse the allocated memory for
sequent cursor allocations in other programs (like another instance of
`memleak`) once the program triggering the bug gets terminated. Test this by
running several instances of `memleak` one after another.
So for now till someone with more knowlegde of XFree86 code fixes the bug a
simple workaround is to avoid animated cursors. There may be a bug in
gdk_cursor_unref() too, I haven't checked the code. In any case, I think it's
a big (security?) problem in the X server code, because any malicious app can
make X server (which is generally running as root on most systems with DM)
use large amounts of memory by repeatedly allocating memory for the cursor
and not freeing it aftwerwards.
It would be great if someone could test this test case on Xorg. Lots of
distros include animated watch cursors by default these days, and if these
are big, lots of people might be suffering from this bug.
The "fixed" gpdf (with the offensive code commented out) is available here[4]
(the binary for i386, provided there, is compiled w/o optimizations and
debugging symbols are unstripped)
Related bugs in other locations (neither of which is marked as fixed):
https://bugs.freedesktop.org/show_bug.cgi?id=1043
http://bugs.gentoo.org/show_bug.cgi?id=31982
[1]. http://www.kde-look.org/content/show.php?content=18214
[2]. http://mif.vu.lt/~mova3971/xf/watch
[3]. http://mif.vu.lt/~mova3971/xf/memleak.c
[4]. http://mif.vu.lt/~mova3971/xf/gpdf
pgpvX8xz0JQUj.pgp
Description: PGP signature
Bug#281050: xserver-common: [i810] Memory leak
On Tue, 2005-01-18 at 11:59 +0200, Gintautas Miliauskas wrote: > > I intended to say by the second paragraph that it would might be more > useful to use X.Org for everyday work. I am not sure if Ubuntu's X.Org > can be installed without problems on a standard Debian unstable system, I and other people have done it without serious problems. > and I am not aware of any unofficial X.Org packages. A repository of such has been posted to the debian-x list as well, but I think they're basically rebuilds of the Ubuntu packages. -- Earthling Michel DÃnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
Bug#281050: xserver-common: [i810] Memory leak
Hello, > > > I just tried gpdf on a large file with X.Org on Ubuntu Hoary (booted > > > from a live CD). It appears that the problem is still there, but to a > > > lesser extent. The PDF file that made XFree86 suck 200+ MB only > > > expanded the X.Org server to 60-70MB. After a few minutes usage dropped > > > to 45MB. While it is still noticeable, the effect is significantly > > > smaller. > > > > > > Since gpdf is just a very vague and imprecise indicator of the actual > > > problem of X sucking up large amounts of memory over extended periods of > > > time, it would probably be more useful to try to run X.Org in real-life > > > situations. I am contemplating migration to Hoary, but I am not sure > > > that I can find time to do that. > > > > You don't have to do a wholesale upgrade to hoary to run X.org from it. > > Indeed, if you need a Hoary/X.org environment to help with > testing/reproducing a bug, one option is to try the (rough, but functional) > Hoary live CD: > > http://cdimage.ubuntu.com/daily-live/current/ Thanks for the pointer, but I did use the Hoary live CD, as noted in the first of the two paragraphs you cited. I intended to say by the second paragraph that it would might be more useful to use X.Org for everyday work. I am not sure if Ubuntu's X.Org can be installed without problems on a standard Debian unstable system, and I am not aware of any unofficial X.Org packages. Even then, X is a critical piece of software so I would think twice before jumping onto some untested package. I mentioned Hoary because if I upgraded to it, the X upgrade problem would be solved and I would be using standard, tested packages. Thanks for your assistance, everyone, -- Gintautas Miliauskas http://gintasm.blogspot.com signature.asc Description: =?iso-8859-2?Q?=A9i?= =?iso-8859-2?Q?_lai=B9ko?= dalis yra =?iso-8859-2?Q?pasira=B9yta?= skaitmeniniu =?iso-8859-4?Q?b=FEdu?=
Bug#281050: xserver-common: [i810] Memory leak
On Sun, Jan 16, 2005 at 04:50:04PM -0500, Michel Dänzer wrote: > On Fri, 2005-01-14 at 23:22 +0200, Gintautas Miliauskas wrote: > > > > I just tried gpdf on a large file with X.Org on Ubuntu Hoary (booted > > from a live CD). It appears that the problem is still there, but to a > > lesser extent. The PDF file that made XFree86 suck 200+ MB only > > expanded the X.Org server to 60-70MB. After a few minutes usage dropped > > to 45MB. While it is still noticeable, the effect is significantly > > smaller. > > > > Since gpdf is just a very vague and imprecise indicator of the actual > > problem of X sucking up large amounts of memory over extended periods of > > time, it would probably be more useful to try to run X.Org in real-life > > situations. I am contemplating migration to Hoary, but I am not sure > > that I can find time to do that. > > You don't have to do a wholesale upgrade to hoary to run X.org from it. Indeed, if you need a Hoary/X.org environment to help with testing/reproducing a bug, one option is to try the (rough, but functional) Hoary live CD: http://cdimage.ubuntu.com/daily-live/current/ -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#281050: xserver-common: [i810] Memory leak
On Fri, 2005-01-14 at 23:22 +0200, Gintautas Miliauskas wrote: > > I just tried gpdf on a large file with X.Org on Ubuntu Hoary (booted > from a live CD). It appears that the problem is still there, but to a > lesser extent. The PDF file that made XFree86 suck 200+ MB only > expanded the X.Org server to 60-70MB. After a few minutes usage dropped > to 45MB. While it is still noticeable, the effect is significantly > smaller. > > Since gpdf is just a very vague and imprecise indicator of the actual > problem of X sucking up large amounts of memory over extended periods of > time, it would probably be more useful to try to run X.Org in real-life > situations. I am contemplating migration to Hoary, but I am not sure > that I can find time to do that. You don't have to do a wholesale upgrade to hoary to run X.org from it. -- Earthling Michel DÃnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
Bug#281050: xserver-common: [i810] Memory leak
Hello. I just want to add that the reported problem is not a generic debian one. I have the same problem with an Intel 855GME chipset running Fedora Core 3. Since this bugreport is the only reference I found on google I want to add some notes here. Running both the stable 6.8.1 and the development release 6.8.1.902 of X.Org I see the X-Server consuming more and more memory the longer it runs. When started I have around 24 MB resident mem, after several hours that goes up to over 100 MB and some days later most of my 512 MB are used by the X-server and the system starts to swap heavily. Using gpdf I can reproduce that much faster, but also firefox or VMware are able to fill up the memory quickly with no chance to get it free again, beside from restarting the X-Server. As far as I understand from reading the current messages in this bug only some people are affected by this. But since it occurs with both the i810 and the vesa driver (as said by Gintautas Miliauskas) there should be a way to reproduce it on a wider base. Gintautas suggested that it may be some personal tweaking in his configuration that leads to that problem, but I heavily doubt it, since I use a simple configuration myself, which was in fact auto-generated by the system-install programs. If it is any use I will provide pmap outputs or configuration details, I just don't know for what to look at, since everything was already reported here and matches my experiences exactly. Regards, Matthias pgpLjG0N8pN1w.pgp Description: PGP signature
Bug#281050: xserver-common: [i810] Memory leak
Hello, I just tried gpdf on a large file with X.Org on Ubuntu Hoary (booted from a live CD). It appears that the problem is still there, but to a lesser extent. The PDF file that made XFree86 suck 200+ MB only expanded the X.Org server to 60-70MB. After a few minutes usage dropped to 45MB. While it is still noticeable, the effect is significantly smaller. Since gpdf is just a very vague and imprecise indicator of the actual problem of X sucking up large amounts of memory over extended periods of time, it would probably be more useful to try to run X.Org in real-life situations. I am contemplating migration to Hoary, but I am not sure that I can find time to do that. I will probably do the migration during the next few months, but I would not bet on it. P.S. Should I continue to send copies of mails to you directly, or will you pick them out from the Debian bug tracker system (I am not sure if it is sending copies to you automatically)? -- Gintautas Miliauskas <[EMAIL PROTECTED]> signature.asc Description: =?iso-8859-2?Q?=A9i?= =?iso-8859-2?Q?_lai=B9ko?= dalis yra =?iso-8859-2?Q?pasira=B9yta?= skaitmeniniu =?iso-8859-4?Q?b=FEdu?=
Bug#281050: xserver-common: [i810] Memory leak
Hello, I'm CCing my friend, Modestas Vainius, who told me about gpdf's uncanny ability to make X eat lots of memory. Perhaps he could provide some useful information. > I'm sorry it has taken a little while to get back to you. Oh, don't worry. I am very happy that you are helping me. > Well, you could try using a different X display driver. There are two > possibilities: > > 1) vesa > 2) fbdev I have just booted on VESA. I was surprised that it was completely painless -- 1024x768 with 32-bit colours worked out of the box. Anyway, I can still make X hoard memory by opening a large file with gpdf. I have also tried to boot kernel 2.4.25 (instead of 2.6.8, which I'm running now), just in case, but the result was absolutely the same. I did not try fbdev, because I had trouble with the framebuffer on this laptop and framebuffer support is disabled in the kernel. Anyway, as far as I understand it the idea here is to make sure that the bug is not in the i810 driver. > If you can reproduce your resource leak problems with either or both of > these drivers, then I strongly suspect a problem in the hardware-neutral > parts of the XFree86 DDX implementation (which I think is mostly stubs), or > the DIX portion. But then the big question is, why don't other people notice this? If it's in a generic layer, the problem should be visible everywhere. > Thanks for your indulgence with my proposed experiments, and I'm sorry they > did not mitigate or rectify the issue. Well, it's the least I can do as I *really* want this problem fixed. By now I have developed a strong feeling that I'm on something that is either expected behaviour or a result of a personal tweak. Maybe the resources should be cleaned up some time after the program using it is gone? The problem did not solve itself for me though. Actually in other systems I have seen X use lots of virtual RAM after extended periods of uptime, but the resident portion was never that large. It also does not seem to get swapped out easily. I am also very uncomfortable that the only quick and reliable way to reproduce this is with gpdf. It could be a bug in gpdf, or maybe in both X and gpdf that causes the problem. I think that it might be a good idea to try X.Org and see if the problem persists. I will try booting the Ubuntu (hoary) live CD tomorrow which runs X.Org and see if the problem manifests itself there as well. -- Gintautas Miliauskas <[EMAIL PROTECTED]> signature.asc Description: =?iso-8859-2?Q?=A9i?= =?iso-8859-2?Q?_lai=B9ko?= dalis yra =?iso-8859-2?Q?pasira=B9yta?= skaitmeniniu =?iso-8859-4?Q?b=FEdu?=
Bug#281050: xserver-common: [i810] Memory leak
Hello, > Anyway, one way to test at least parts of my hypothesis would be simply to > turn off the XAA pixmap cache. To do this, add the following line to the > "Device" section of your XF86Config-4 file: > >Option "XaaNoPixmapCache" > > It might be worth trying the following as well: > >Option "XaaNoOffscreenPixmaps" > > Both of the above are documented in XF86Config-4(5x), by the way. I added both of these to the "Device" section, didn't change anything. I also tried to add them to the "Screen" section (as the manual says), without any difference either. Taking this a step further, I completely disabled XAA (Option "Accel" "off"). It did wonders to slowing my system to a crawl, yet gpdf would still hoard memory, which means that the problem has not gone away. I presume that these results do not go well with your hypothesis? Is there anything else I can do to at least help find out which part of X is the culprit? This bug is really a PITA for me (I even made a tiny cron script that mails me if X takes up more than 80MB (resident); it takes about two days to reach that threshold). Thanks for your help, -- Gintautas Miliauskas <[EMAIL PROTECTED]> signature.asc Description: Ši laiško dalis yra pasirašyta skaitmeniniu būdu
Bug#281050: xserver-common: [i810] Memory leak
On Thu, 2004-12-16 at 21:28 +, Anders Karlsson wrote: > > You might try experimenting with the XAA pixmap options as I just suggested > > in my mail to Gintautas Miliauskas; see > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=284448 > for it. > > I will give that a shot. I should see in less than 12 hours if that has > any effect on memory usage in X really. Right, three hours usage of Gnome and X.org (same thing observed on XFree86) with the two options XaaNoPixmapCache and XaaNoOffscreenPixmaps set has resulted in 'ps waux' telling me about X that it is taking up 127 MiB in the RSS section and in total 157 MiB. At the same time xrestop claims there are 22 clients, Pixmaps 11660K, Other 459K and All 12120K. Biggest client usage is 3756 KiB according to xrestop. Running 'pmap' on the PID of the X server gives me one line that stands out like a sore thumb, 08794000 106412K rw---[ anon ] If there was a way to track what processes are using that part of the X server, perhaps I could then find out exactly what program it is that is allocating memory and not freeing it. For the time being, I will avoid using Gnome as that seems to be what is aggravating the issue. Regards, -- Anders Karlsson <[EMAIL PROTECTED]> Trudheim Technology Limited signature.asc Description: This is a digitally signed message part
Bug#281050: xserver-common: [i810] Memory leak
On Wed, 2004-12-15 at 15:48 -0500, Branden Robinson wrote: > On Sun, Dec 12, 2004 at 01:39:35AM +, Anders Karlsson wrote: > > > > I had not read that particular entry, but have read it now. I already > > knew how the X server worked though, about caching pixmaps etc. > > Okay -- sorry for the redundancy. No need to apologise. :-) You are right to point out that there is information that should be read, and taken into account. > > > 2) Do you think you are experiencing the same problem as seen in bug > > >#279940? > > > > > >http://bugs.debian.org/279940 > > > > I am experimenting with that now, although my results will not be > > relevant to this case anymore, as I have migrated the problematic > > machine onto Ubuntu. If the "leak" I experience is in the flash plugin, > > I should still see the problem, even if I have ditched XFree86 in favour > > of X.org. Okay, I'll add some information on this. I am now running Ubuntu Hoary (Sid equivalent) with X.org 6.8.1. Using KDE 3.3, no problem, memory usage of X in total rarely went over 80 MiB. Then I switched back to Gnome In three hours, X has grown to have a 135 MiB rss section. xrestop says there is 31.6 MiB total use of X. Might be worth checking with anyone else seeing this problem if they are using Gnome at all. Does the problem go away when using KDE? When I was running OpenBox as window manager, I was still running gnome-panel and gnome-settings-daemon. Those two apps could be culprits of the 'memory leak'. I could be talking out of my ass here, but I am just thinking out loud. > > > 3) Can you please use the "xrestop" program and provide (text) screenshots > > >of its operation, so we can see if there are any culpable clients? > > > > Uhm, as I said above, my results will probably not have any bearing on > > this defect anymore. If it looks like the flash problem, I will post > > snapshots of xrestop. It should be Firefox eating huge amounts of X > > memory but I would have thought that closing the browser should free > > that memory from the X server, or is that a wrong assumption... > > You might try experimenting with the XAA pixmap options as I just suggested > in my mail to Gintautas Miliauskas; see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=284448 > for it. I will give that a shot. I should see in less than 12 hours if that has any effect on memory usage in X really. Regards, -- Anders Karlsson <[EMAIL PROTECTED]> Trudheim Technology Limited signature.asc Description: This is a digitally signed message part
Bug#281050: xserver-common: [i810] Memory leak
On Sun, Dec 12, 2004 at 01:39:35AM +, Anders Karlsson wrote: > > 1) Have you read the Debian X FAQ entry on this issue? > > > > > > http://necrotic.deadbeast.net/xsf/XFree86/trunk/debian/local/FAQ.xhtml#xservmemory > > I had not read that particular entry, but have read it now. I already > knew how the X server worked though, about caching pixmaps etc. Okay -- sorry for the redundancy. > > 2) Do you think you are experiencing the same problem as seen in bug > >#279940? > > > >http://bugs.debian.org/279940 > > I am experimenting with that now, although my results will not be > relevant to this case anymore, as I have migrated the problematic > machine onto Ubuntu. If the "leak" I experience is in the flash plugin, > I should still see the problem, even if I have ditched XFree86 in favour > of X.org. > > > 3) Can you please use the "xrestop" program and provide (text) screenshots > >of its operation, so we can see if there are any culpable clients? > > Uhm, as I said above, my results will probably not have any bearing on > this defect anymore. If it looks like the flash problem, I will post > snapshots of xrestop. It should be Firefox eating huge amounts of X > memory but I would have thought that closing the browser should free > that memory from the X server, or is that a wrong assumption... You might try experimenting with the XAA pixmap options as I just suggested in my mail to Gintautas Miliauskas; see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=284448 > for it. -- G. Branden Robinson| "To be is to do" -- Plato Debian GNU/Linux | "To do is to be" -- Aristotle [EMAIL PROTECTED] | "Do be do be do" -- Sinatra http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Bug#281050: xserver-common: [i810] Memory leak
On Sat, Dec 11, 2004 at 06:27:28PM +0200, Gintautas Miliauskas wrote: > I have read the entry, but I don't think I have learned anything I don't > know already. Hmm, well, I guess the FAQ can't contain *all* knowledge. :) > > 2) Do you think you are experiencing the same problem as seen in bug > >#279940? > > > >http://bugs.debian.org/279940 > > Possibly; the symptoms are similar. However, I'm sure it's not the > flash plugin that is causing problems. My friend also has this problem, > and he found a way to reproduce it with gpdf (Gnome's PDF viewer). Just > use gpdf to open a largish PDF file (the IBM DB2 reference at > ftp://ftp.software.ibm.com/ps/products/db2/info/vr82/pdf/en_US/db2s1e81.pdf > having 900 pages worked well for me), and watch X memory usage soar. > Closing gpdf afterwards does not help, however, opening the same file > with gpdf again does not eat yet another 200MB of memory. This smells very much like a resource leak to me. > It could mean that some buffer is allocated by X and then enlarged as > needed, but not shrunk later when it's not in use any more. Sounds plausible. > It's interesting to notice that memory is sucked further even when I'm > browsing the already opened PDF file; I just held for a few > moments (the page counter went up to 297), waited for gpdf to stop CPU > activity (I think it was rendering every page) and then I saw that X ate > another 30MB. xrestop also showed a several thousand increase in the > 'Extra' column. Yeesh. > By the way, I'm not sure, but I think my friend said that he had an ATI > video card. If the leak is in the part of the server that it sounds like (DIX), it should be completely hardware-neutral. > I tried to reproduce this problem on several other machines (I don't > know their hardware configurations, but I'm pretty sure the software is > up to date, i.e., testing or unstable), but the problem did not manifest > itself on those machines -- gpdf happily opened the files without any > significant side effects. I have little idea why the problem exists on > my machine and on my friend's machine, but not on the others that I have > tested. Huh, well, damn. I could be wrong about the problem being in the DIX layer, then. > > 3) Can you please use the "xrestop" program and provide (text) > > screenshots of its operation, so we can see if there are any > > culpable clients? > > I am attaching snapshots of top, pmap and xrestop before starting gpdf > (suffix ".before"), after opening the DB2 reference with gpdf (suffix > ".after", and after closing gpdf (suffix ".closed"). My XF86Config-4 > and output of xdpyinfo are included as well. > > Note that I wasn't using gpdf previously (nor was I opening large PDFs), > so I don't think you should put all the blame on it as you did for the > flash plugin. I am experiencing a gradual increase of memory usage > rather than sudden jumps. There might be a bug in gpdf, but I am > concerned with the fact that the memory is not released even after I > quit gpdf. I wonder if there is some stupid bug where some kind of backing store for the pixmap cache is being established, but never recycled. I don't really know how this stuff works in detail, but I do know that XAA (X acceleration architecture) let exposes the display adapter's 2D acceleration features to the X server, and one of those features is use of parts of video memory as a pixmap cache. It seems to me that an implementor might want to keep a shadow pixmap cache in main memory inside the X server, especially with the crazy 3D hardware we have these days, which you sometimes have to reset when they lock-up, which in turn (for all I know) could zero out or corrupt the video RAM. Of course, not all driver authors may want to have a shadow cache in main memory, and/or a display adapter that didn't have 3D acceleration features might not use them. There's my crazy hypothesis for why this behavior might be seen only on Radeon and i855 cards, but not others (they both have DRI drivers). Hopefully if it's laughably off-base, some knowledgeable person will be provoked into replying this message to set my delusional ass straight. Anyway, one way to test at least parts of my hypothesis would be simply to turn off the XAA pixmap cache. To do this, add the following line to the "Device" section of your XF86Config-4 file: Option "XaaNoPixmapCache" It might be worth trying the following as well: Option "XaaNoOffscreenPixmaps" Both of the above are documented in XF86Config-4(5x), by the way. > I now tried opening several large apps (OpenOffice.org, GIMP, Eclipse, > etc.) and some of the hogged-up memory was swapped out (resident block > of X fell from 230MB to 107MB). At least that stuff swaps out, but it > still makes my system rather slow (perhaps because it starves the > filesystem cache). Possibly. > Another very thing I have experienced a few times is an almost-complete > freeze of my machine when exiting
Bug#281050: xserver-common: [i810] Memory leak
On Fri, 2004-12-10 at 13:04 -0500, Branden Robinson wrote: [snip] > > I have some questions for you gentlemen: No problem, I will try and answer as best as I can. > 1) Have you read the Debian X FAQ entry on this issue? > > > http://necrotic.deadbeast.net/xsf/XFree86/trunk/debian/local/FAQ.xhtml#xservmemory I had not read that particular entry, but have read it now. I already knew how the X server worked though, about caching pixmaps etc. > 2) Do you think you are experiencing the same problem as seen in bug >#279940? > >http://bugs.debian.org/279940 I am experimenting with that now, although my results will not be relevant to this case anymore, as I have migrated the problematic machine onto Ubuntu. If the "leak" I experience is in the flash plugin, I should still see the problem, even if I have ditched XFree86 in favour of X.org. > 3) Can you please use the "xrestop" program and provide (text) screenshots >of its operation, so we can see if there are any culpable clients? Uhm, as I said above, my results will probably not have any bearing on this defect anymore. If it looks like the flash problem, I will post snapshots of xrestop. It should be Firefox eating huge amounts of X memory but I would have thought that closing the browser should free that memory from the X server, or is that a wrong assumption... Regards, -- Anders Karlsson <[EMAIL PROTECTED]> Trudheim Technology Limited signature.asc Description: This is a digitally signed message part
Bug#281050: xserver-common: [i810] Memory leak
Hello, > 1) Have you read the Debian X FAQ entry on this issue? > >.../xsf/XFree86/trunk/debian/local/FAQ.xhtml#xservmemory I have read the entry, but I don't think I have learned anything I don't know already. > 2) Do you think you are experiencing the same problem as seen in bug >#279940? > >http://bugs.debian.org/279940 Possibly; the symptoms are similar. However, I'm sure it's not the flash plugin that is causing problems. My friend also has this problem, and he found a way to reproduce it with gpdf (Gnome's PDF viewer). Just use gpdf to open a largish PDF file (the IBM DB2 reference at ftp://ftp.software.ibm.com/ps/products/db2/info/vr82/pdf/en_US/db2s1e81.pdf having 900 pages worked well for me), and watch X memory usage soar. Closing gpdf afterwards does not help, however, opening the same file with gpdf again does not eat yet another 200MB of memory. It could mean that some buffer is allocated by X and then enlarged as needed, but not shrunk later when it's not in use any more. It's interesting to notice that memory is sucked further even when I'm browsing the already opened PDF file; I just held for a few moments (the page counter went up to 297), waited for gpdf to stop CPU activity (I think it was rendering every page) and then I saw that X ate another 30MB. xrestop also showed a several thousand increase in the 'Extra' column. By the way, I'm not sure, but I think my friend said that he had an ATI video card. I tried to reproduce this problem on several other machines (I don't know their hardware configurations, but I'm pretty sure the software is up to date, i.e., testing or unstable), but the problem did not manifest itself on those machines -- gpdf happily opened the files without any significant side effects. I have little idea why the problem exists on my machine and on my friend's machine, but not on the others that I have tested. > 3) Can you please use the "xrestop" program and provide (text) > screenshots of its operation, so we can see if there are any > culpable clients? I am attaching snapshots of top, pmap and xrestop before starting gpdf (suffix ".before"), after opening the DB2 reference with gpdf (suffix ".after", and after closing gpdf (suffix ".closed"). My XF86Config-4 and output of xdpyinfo are included as well. Note that I wasn't using gpdf previously (nor was I opening large PDFs), so I don't think you should put all the blame on it as you did for the flash plugin. I am experiencing a gradual increase of memory usage rather than sudden jumps. There might be a bug in gpdf, but I am concerned with the fact that the memory is not released even after I quit gpdf. I now tried opening several large apps (OpenOffice.org, GIMP, Eclipse, etc.) and some of the hogged-up memory was swapped out (resident block of X fell from 230MB to 107MB). At least that stuff swaps out, but it still makes my system rather slow (perhaps because it starves the filesystem cache). Another very thing I have experienced a few times is an almost-complete freeze of my machine when exiting a heavy app (I remember experiencing it with Eclipse and some other programs too). Even the mouse cursor stops moving, and for about one minute there is very intensive hard disk activity. Then the system starts responding again as if nothing had happened. I could not find anything interesting in the logs or output of `top`. This might not be related to this bug, but I'm including it in case other people have experienced such a thing too. My machine is a Toshiba laptop with a 2.2GHz P4 and 512MB of RAM, Intel 855GM video chipset, I'm using Debian unstable. I hope I provided some useful information (I will be happy to provide more if you need anything else). It's a pity that I don't really have time right now (well, to be honest, not quite enough experience either...) to fire up a debugger and chase the culprit myself. -- Gintautas Miliauskas <[EMAIL PROTECTED]> x-leak-info.tar.gz Description: application/compressed-tar signature.asc Description: Ši laiško dalis yra pasirašyta skaitmeniniu būdu
Bug#281050: xserver-common: [i810] Memory leak
retitle 281050 xserver-xfree86: server has memory leaks reassign 281050 xserver-xfree86: server has memory leaks severity 281050 normal tag 281050 + moreinfo thanks On Sat, Nov 13, 2004 at 04:01:34PM +0100, Piotr Roszatycki wrote: > Package: xserver-common > Version: 4.3.0.dfsg.1-8 > Severity: important > > # pmap 9617 > 9617: /usr/X11R6/bin/X -nolisten tcp -auth /var/run/xauth/A:0-tkybcM > vt7 [...] > total 936844K On Mon, Nov 29, 2004 at 09:30:13PM +0200, Gintautas Miliauskas wrote: > I'm experiencing heavy XFree86 memory leaking as well. I killed the > process before finding out about this bug report, so I can't provide any > useful info right now. Over around 100 hours of active usage the > resident part grew to more than 200MB (right now after restarting X it > is a mere 16MB), and the system became really sluggish. > > The bug should not be related to a particular desktop environment or > application: I have switched to GNOME a couple of days ago, because I > thought KDE was slow -- but apparently this leak had been the problem > all the time! It somehow never struck me to check the memory usage of > the X server, until now. > > Please fix this bug, it is *extremely* annoying and disappointing to think > that I will have to restart every couple days to have a usable system. On Mon, Nov 29, 2004 at 11:38:44PM +, Anders Karlsson wrote: > The memory leak is prevalent on the radeon chipset as well. As Gintautas > Miliauskas described, after about 100 hours runtime, the X server is > taking up about 250+ MB of resident memory. I tend to have running > openbox, gnome-panel, firefox, xchat and a few WindowMaker applets. > > If this could be fixed, it would certainly make work easier. I have some questions for you gentlemen: 1) Have you read the Debian X FAQ entry on this issue? http://necrotic.deadbeast.net/xsf/XFree86/trunk/debian/local/FAQ.xhtml#xservmemory 2) Do you think you are experiencing the same problem as seen in bug #279940? http://bugs.debian.org/279940 3) Can you please use the "xrestop" program and provide (text) screenshots of its operation, so we can see if there are any culpable clients? -- G. Branden Robinson| Measure with micrometer, Debian GNU/Linux | mark with chalk, [EMAIL PROTECTED] | cut with axe, http://people.debian.org/~branden/ | hope like hell. signature.asc Description: Digital signature
Processed: Re: Bug#281050: xserver-common: [i810] Memory leak
Processing commands for [EMAIL PROTECTED]: > retitle 281050 xserver-xfree86: server has memory leaks Bug#281050: xserver-common: [i810] Memory leak Changed Bug title. > reassign 281050 xserver-xfree86: server has memory leaks Bug#281050: xserver-xfree86: server has memory leaks Warning: Unknown package 'server' Warning: Unknown package 'has' Warning: Unknown package 'memory' Warning: Unknown package 'leaks' Bug reassigned from package `xserver-common' to `xserver-xfree86: server has memory leaks'. > severity 281050 normal Bug#281050: xserver-xfree86: server has memory leaks Warning: Unknown package 'server' Warning: Unknown package 'has' Warning: Unknown package 'memory' Warning: Unknown package 'leaks' Severity set to `normal'. > tag 281050 + moreinfo Bug#281050: xserver-xfree86: server has memory leaks There were no tags set. Warning: Unknown package 'server' Warning: Unknown package 'has' Warning: Unknown package 'memory' Warning: Unknown package 'leaks' Tags added: moreinfo > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Bug#281050: xserver-common: [i810] Memory leak
Package: xserver-common Version: 4.3.0.dfsg.1-8 Severity: important # pmap 9617 9617: /usr/X11R6/bin/X -nolisten tcp -auth /var/run/xauth/A:0-tkybcM vt7 640K rw-s-[ shmid=0x1 ] 000a128K rwxs- /mem 000c192K rwxs- /mem 000f 64K r-xs- /mem 08048000 1512K r-x-- /XFree86 081c2000196K rw--- /XFree86 081f3000 682248K rw---[ anon ] a7708000 50720K rw---[ anon ] aa8d5000 7608K rw---[ anon ] ab20e000 7608K rw---[ anon ] aba07000 1520K rw---[ anon ] abb83000 1876K r--s-[ shmid=0x117000f ] abd58000 5072K rw---[ anon ] ac293000260K rw---[ anon ] ac2f3000384K rw---[ anon ] ac353000384K rw-s-[ shmid=0x115800e ] ac3f6000 8K rw---[ anon ] ac436000484K rw---[ anon ] ac4ec000 8K rw---[ anon ] ac52c000 1480K rw---[ anon ] ac70 5072K rw---[ anon ] ad029000384K rw-s-[ shmid=0x115000d ] ad089000 5072K rw---[ anon ] ad5bd000 8K rw---[ anon ] ad796000368K rw---[ anon ] ad897000252K rw---[ anon ] ad922000 5680K rw---[ anon ] adf46000 5072K rw---[ anon ] ae47b000 1768K rw---[ anon ] ae765000376K rw---[ anon ] ae829000508K rw---[ anon ] ae9c8000 8K rw---[ anon ] aea08000760K rw---[ anon ] aeb45000 5072K rw---[ anon ] af088000908K rw---[ anon ] af218000 1112K rw---[ anon ] af37a000608K rw---[ anon ] af4ea000 6152K rw---[ anon ] afaec000 36K r-x-- /libnss_files-2.3.2.so afaf5000 4K rw--- /libnss_files-2.3.2.so afb0f000228K rw---[ anon ] afb7f000228K rw---[ anon ] afbef000228K rw---[ anon ] afc5f000228K rw---[ anon ] afccf000 64K rw-s- /mem afcdf000 131072K rw-s- /mem b7cdf000512K rw-s- /mem b7d5f000 8K rw-s- /card0 b7d61000640K rw-s-[ shmid=0x1 ] b7e01000328K rw---[ anon ] b7e53000 1216K r-x-- /libc-2.3.2.so b7f83000 32K rw--- /libc-2.3.2.so b7f8b000 12K rw---[ anon ] b7f8e000 32K r-x-- /libgcc_s.so.1 b7f96000 4K rw--- /libgcc_s.so.1 b7f97000 8K r-x-- /libdl-2.3.2.so b7f99000 4K rw--- /libdl-2.3.2.so b7f9a000136K r-x-- /libm-2.3.2.so b7fbc000 4K rw--- /libm-2.3.2.so b7fbd000 4K rw---[ anon ] b7fbe000 68K r-x-- /libz.so.1.2.2 b7fcf000 4K rw--- /libz.so.1.2.2 b7fe9000 4K rw---[ anon ] b7fea000 88K r-x-- /ld-2.3.2.so b800 4K rw--- /ld-2.3.2.so bffee000 72K rwx--[ stack ] e000 4K -[ anon ] total 936844K -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (900, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.9-1-686 Locale: LANG=pl_PL, LC_CTYPE=pl_PL (charmap=ISO-8859-2) Versions of packages xserver-common depends on: ii debconf [debconf-2.0] 1.4.40 Debian configuration management sy ii libc6 2.3.2.ds1-18 GNU C Library: Shared libraries an ii xfree86-common4.3.0.dfsg.1-8 X Window System (XFree86) infrastr -- debconf information: * xserver-common/xwrapper/nice_value: -10 xserver-common/using_obsolete_xserver: * xserver-common/xwrapper/allowed_users: Console Users Only xserver-common/xwrapper/actual_allowed_users: console xserver-common/xwrapper/nice_value/error: * xserver-common/clobber_xwrapper_config: false * xserver-common/aware_xwrapper: xserver-common/xwrapper/old_config_file_obsolete:
