On Fri, 03 Nov 2000 02:59:46 EST, Wolfgang Sourdeau <wolfgang ultim net> 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
Attachment:
pgp7Zvt93wmMX.pgp
Description: PGP signature