martin@MEDIA-LAB.MEDIA.MIT.EDU (Martin Friedmann) (03/08/90)
I once had to find memory leaks in the X11 server, The way I did it, and this worked quite well, was I made a macro called malloc and free that added 8 bytes to the size of each block malloc'd and stored __FILE__ and __LINE__. The malloc then stored each block's address in a linear array and searched it freeing up the guys when they were free'd (another macro). Then I made a procedure to print out the malloc list, with the __LINE__ and __FILE__ where the not free'd thhings were allocated. I placed a call to the print procedure in some special X request, and made a client that called that request... This worked well for calls to malloc, but it turned out that the offending leak at the time was not freeing up a higher level structure allocated in InitQuadMesh or something that lots of people called... If the leak is a missing DEALLOCATE_LOCAL, then this will work VERY well in finding the leak. If the leak is the failure to free a block of memory allocated in some procedure (CreateWindow) and freed in DestroyWindow, then this method will do little but hint at the possible places where the leak is, as all that will show up for __LINE__ and __FILE__ will be the malloc in CreateWindow... You could also go the extra mile of putting the clientid of the client that allocated the thing... this may be harder and require the use of hacked up globals as the clientid won't be bound at all times... As a friend of mine at DEC says "Oh, I dunno, do what you want..." Marty.
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (03/08/90)
There are a number of mechanisms for memory debugging already built in to the R4 server code. One need only browse mit/server/os/4.2bsd/utils.c and read mit/doc/Server/r4.tbl.ms.