On Fri, 03 Nov 2000 02:59:46 EST, Wolfgang Sourdeau <[EMAIL PROTECTED]> said:
> I have done some tests and I can confirm that memory is leaking on the
> server side when gdkpixmap are not explicitly destroyed.
> Shouldn't this be considered as a bug in gdk ?
First off, this is *NOT* a gdk bug, because the server:
a) doesn't *know* the client is gdk
b) should be bullet-proof against anything the client does.
If it's anybody's fault, it's the servers.
Now, double check *very* carefully here.
Is memory actually *leaking* from the X server, or is storage being
*fragmented*? There's a big distinction here, and the fix is different
for each case.
If it is *leaking*, this means that the X server is calling malloc() to
allocate space and failing to call free() to release it.
<We now digress into a vastly over-simplified discussion of malloc() internals>
If it is *fragmenting*, the X server *is* calling free(), but the resulting
memory layout is sub-optimal. For example, consider the following code:
char *x[4];
x[0] = malloc(40);
x[1] = malloc(1);
x[2] = malloc[40);
x[3] = malloc(1);
free(x[0]);
free(x[2]);
Memory would possibly now look like this:
|<-40 bytes of free->||<1 byte>||<40 free>||<1 byte>|
So 2 allocated bytes are taking up 82 bytes of memory. If you then try to
malloc(45), it can't use either of those 2 spaces, so it has to go to the
end and allocate THERE. Now, if the owner if the first 1-byte block
calls free(), any modern malloc package will re-group all 81 bytes into
one larger free block.
The problem is that inside the X server, the 2 40-byte allocations could
have come from ONE X client that has since exited, byut the 2 1-byte
allocations have come from some OTHER client that is still running, so
you can't free that memory until THAT process exits. And usually, there's
a lot more than 2 clients running (quite often, I have 30 or 40 client
programs running). So it's *very* easy for memory to get very fragmented
inside the X server.
Unfortunately, C does not have any good garbage-collection scheme for compacting
the allocated memory - the problem is that the garbage collector has no way
of knowing what variables in the program have pointers to the to-be-moved
allocation, so it can't relocate allocated memory.
I've checked both the IBM AIX 4.3.3 X server, and the XFree 4.0.1 server
on my Linux box, and both of them quite quickly bloat up to about 50M in
size.
--
Valdis Kletnieks
Operating Systems Analyst
Virginia Tech
PGP signature
