Am 30.09.2005 um 19:28 schrieb Gustaf Neumann:
What tools or tricks are useful for tracking down memory leaks in Tcl or XOTcl?
Tricks? No tricks. Hard work and lots of money to spend on good memory analyzer (Purify), heh...
And, watching "top" output for hours while doing "time {....} 100000" on some spots you *suspect* may be raining on your party!
Honestly, this is one of the most ugly time consuming boring unproductive difficult stupid (... you name it ...)
tasks you can imagine. Have been doing this for quite a few years already, so I know what I'm saying.
Couple of hints...
Is your Tcl or your C-code leaking? (this is not as dumb question as it may appear on the first glace...)
If you are using threads, try in a non-threaded env.
Try isolating parts of your code by divide/conquer method (start from top and work yourself down) and use "time" to repeat sections of code. At the same time keep an eye on the "top" utility... (Poor Man's Purify)
If you are running in an event mode, do you clean event loop fast enough?
If possible, try compilng *ALL* the C-code you use with -DTCL_MEM_DEBUG and read "memory" man-page. This is somehow difficult to use (gives A LOT of info) but in some cases it saved my skin.
As of my experience, Tcl/XOTcl are leak-free. If not I'd already scream aloud. If you are using any other C-level extensions, well...
If not, then most probably you do not care enough about destroying the objects. What I do is to (mostly) instantiate objects like this:
Object new -volatile
which guarantees to garbade-collect them when the scope (i.e. proc) were I new'ed them is gone. This won't work for "globaly" needed objects, though...
Memory "leaks" can be quite "hidden", for example arrays getting larger, lists getting longer, etc. etc. Those are not "leaks" per-se, hence never caught by any C-level memory debugger. For that you'd need to employ the poor-man's purify, like described above.
Eh... good luck!
Zoran