The memory command provides various facilities for debugging Tcl's memory management. It is only available when Tcl is configured to include memory debugging; this is not a default configuration because of the performance penalty involved.
BAS I'm not an expert on this command, but just recently used it, and it was quite helpful. So I thought I would just jot down some notes for others.
First, you need to have TCL_MEM_DEBUG defined in your tclsh/wish. I was testing an extension, so I also set it in the extension...not sure if that is needed. By setting that option, it gives you the memory command, and also puts guards around any memory allocation.
How I used it, was I would use memory info and memory onexit. memory info will give you a status on memory allocates that were performed (it dumps it to a file). It looks like this:
total mallocs 3758 total frees 2686 current packets allocated 1072 current bytes allocated 75445 maximum packets allocated 1371 maximum bytes allocated 91655
memory onexit (and memory active), will give will dump active allocs to a file, and looks like this:
808ccd0 - 808cd5b 140 @ ../generic/tclCompile.c 1581 8063910 - 806391b 12 @ ../generic/tclLiteral.c 290 808c9e8 - 808c9eb 4 @ ../generic/tclLiteral.c 267 808c898 - 808c8af 24 @ ../generic/tclLiteral.c 261 808c788 - 808c793 12 @ ../generic/tclLiteral.c 290 806b210 - 806b216 7 @ ../generic/tclLiteral.c 267 808cde0 - 808cdf7 24 @ ../generic/tclLiteral.c 261 . . .
So, if the memory info report showed a very big difference between the mallocs and frees, I would look in the memory onexit report, and grep for any lines that had my extension files in it. It gives the line numbers, so you just need to go the line number, and then figure out why it complaining. Most of my problems were that I was not freeing correctly, so I would just make sure I would free that malloc.