Re: [Xotcl] memory leak analysis

From: Ben Thomasson <ben.thomasson_at_gmail.com>
Date: Fri, 30 Sep 2005 14:28:27 -0400

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