Thanks for the advice. I have made sure to garbage collect my unneeded objects. I need<br>
to look into those other sources of memory usage.<br>
<br>
My application is soley Tcl/XOTcl and does not use threads. The majority of the code is <br>
XOTcl. There are no C extensions.<br>
<br>
I am using introspection to find objects and values of the variables in those objects. This<br>
has been very helpful in identifying "lost objects."<br>
<br>
I will recompile the tcl and xotcl binaries to enable memory usage commands. I still<br>
suspect a list or array out of control. I guess I am in for a few more nights of staring<br>
at top.<br>
<br>
Thanks for the time { ... } 10000... idea. That will be useful in my unit tests.<br>
<br>
Thanks,<br>
<br>
Ben<br>
<br>
>xotclsh<br>
% package require XOTcl<br>
1.3.6<br>
% package require Tcl<br>
8.4<br>
%<br>
<br>
<br><div><span class="gmail_quote">On 30/09/05, <b class="gmail_sendername">Zoran Vasiljevic</b> <<a href="mailto:zv@archiware.com">zv@archiware.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>Am 30.09.2005 um 19:28 schrieb Gustaf Neumann:<br><br>>> What tools or tricks are useful for tracking down memory leaks in<br>>> Tcl or XOTcl?<br><br>Tricks? No tricks. Hard work and lots of money to spend on good
<br>memory analyzer (Purify), heh...<br><br>And, watching "top" output for hours while doing "time {....} 100000"<br>on some spots you *suspect* may be raining on your party!<br><br>Honestly, this is one of the most
<br> ugly<br> time consuming<br> boring<br> unproductive<br> difficult<br> stupid<br> (... you name it ...)<br><br>tasks you can imagine. Have been doing this for quite<br>a few years already, so I know what I'm saying.
<br><br>Couple of hints...<br><br>Is your Tcl or your C-code leaking? (this is not as<br>dumb question as it may appear on the first glace...)<br><br>If you are using threads, try in a non-threaded env.<br><br>Try isolating parts of your code by divide/conquer
<br>method (start from top and work yourself down) and<br>use "time" to repeat sections of code. At the same<br>time keep an eye on the "top" utility... (Poor Man's Purify)<br><br>If you are running in an event mode, do you clean
<br>event loop fast enough?<br><br>If possible, try compilng *ALL* the C-code you use<br>with -DTCL_MEM_DEBUG and read "memory" man-page.<br>This is somehow difficult to use (gives A LOT of<br>info) but in some cases it saved my skin.
<br><br>As of my experience, Tcl/XOTcl are leak-free.<br>If not I'd already scream aloud. If you are<br>using any other C-level extensions, well...<br><br>If not, then most probably you do not care enough<br>about destroying the objects. What I do is to
<br>(mostly) instantiate objects like this:<br><br> Object new -volatile<br><br>which guarantees to garbade-collect them when the scope<br>(i.e. proc) were I new'ed them is gone. This won't work<br>for "globaly" needed objects, though...
<br><br>Memory "leaks" can be quite "hidden", for example arrays<br>getting larger, lists getting longer, etc. etc. Those<br>are not "leaks" per-se, hence never caught by any<br>C-level memory debugger. For that you'd need to employ
<br>the poor-man's purify, like described above.<br><br>Eh... good luck!<br><br>Zoran<br><br><br><br><br><br><br></blockquote></div><br><br clear="all"><br>-- <br>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