Thanks for the advice. I have made sure to garbage collect my unneeded objects. I need to look into those other sources of memory usage.
My application is soley Tcl/XOTcl and does not use threads. The majority of the code is XOTcl. There are no C extensions.
I am using introspection to find objects and values of the variables in those objects. This has been very helpful in identifying "lost objects."
I will recompile the tcl and xotcl binaries to enable memory usage commands. I still suspect a list or array out of control. I guess I am in for a few more nights of staring at top.
Thanks for the time { ... } 10000... idea. That will be useful in my unit tests.
Thanks,
Ben
xotclsh
% package require XOTcl 1.3.6 % package require Tcl 8.4 %
On 30/09/05, Zoran Vasiljevic zv@archiware.com wrote:
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
-- You know you have reached perfection of design not when you have nothing more to add, but when you have nothing more to take away. --Antoine de Saint Exupéry