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 <PageDown> 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 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.
That's probably more of a kernel problem than anything. Even if something
in userspace is making absurd demands ("free 10 GB of virtual memory!"),
the scheduler should not permit such a process to grind the system to a
halt for a full minute.
A worse possibility is that it's the kernel itself bogging down, as tons of
page tables have to be updated. But if I speculate further I'm going to
*really* start talking out of my ass, so I'll stop. (I'm probably wrong,
anyway, as AIUI the page tables are always locked into physical RAM, and
there's just no damn way it should take a whole minute for any modern
machine to do anything with RAM. As you said youself, the hard drive is
thrashing. Presumably it's doing so for some reason.)
> 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.
If you could try the experiments described above, I'd appreciate it.
--
G. Branden Robinson | No executive devotes much effort to
Debian GNU/Linux | proving himself wrong.
branden@debian.org | -- Laurence J. Peter
http://people.debian.org/~branden/ |
Attachment:
signature.asc
Description: Digital signature