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
%
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