No registered users in community xowiki
in last 10 minutes
in last 10 minutes
Re: [Xotcl] memory leak analysis
From: Zoran Vasiljevic <zv_at_archiware.com>
Date: Fri, 30 Sep 2005 19:56:30 +0200
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
Date: Fri, 30 Sep 2005 19:56:30 +0200
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