[lug] x server memory usage and indirect xscreensaver memory leak

[rm at fabula.de]

On Sun, Dec 30, 2001 at 06:36:14PM -0700, Neal McBurnett wrote:
> On Sun, Dec 30, 2001 at 01:51:05PM -0700, D. Stimits wrote:
> > If it is a C app, you can get the electric fence
> > library, and rebuild the app linking with -lfence (I think that is the
> > link, maybe it was -lefence). Anyway, get electric fence, read the man
> > page, it is easy to use. Then run the screen saver from the command
> > line, efence should tell you about possible leaks and bad memory code.
> > I'd like to see it work with C++ new and delete as well, I don't think
> > it works for those though.
> 
> My memory was tied up in the X server, not xscreensaver itself.
> But as soon as I killed xscreensaver, the server's total memory
> size dropped sharply and stayed at a level 77 MB less.

Hmm, it's a while since i last wrote raw X code, but if memory serves
me right a x client program can and will often allocate x resources 
that live in the _servers_ address space. So if an application loads
a hughe image file that image file lives in the x servers memory space,
or am i totally wrong here? (I'll go and chaeck my books ...).

> It would seem like a similar strategy to efence could help.  But
> offhand the info at
>  http://sources.isc.org/devel/memleak/efence.txt
> 
> doesn't suggest that efence would track usage of X11 library calls by
> an X11 client that tie up memory on the server rather than the local
> process.

Yes, indeed. BTW, i'd suggest to use 'debauch' instead of efence since
'debauch' allows you to run tests _without_ recompilation of the program.
But still, this would only show leaks in the server code, _not_ exessive
resource allocation by a client program ... :-/


 Ralf Mattes

> It would seem much more appropriate for the problem I'm tracking to
> just have some code in the X server that tracks down how much memory
> is used by each client.  Even if a true memory leak is not involved,
> it would be nice to know which clients are tying up the most memory
> when you're in a crunch.  Having to figure out which clients are
> connected and how to start each one up via a tool like efence would be
> a big hassle, especially for clients that some other process starts
> like the gnome panel.
> 
> Anyway, thanks for the insights.
> 
> Neal McBurnett <neal at bcn.boulder.co.us>
> http://bcn.boulder.co.us/~neal/
> GPG/PGP signed and/or sealed mail encouraged.  Keyid: 2C9EBA60
>