Why does Tcl leak memory?. It doesn't, with rare exceptions. TCT takes memory leaks very seriously. Few ever escape into a release, and few known ones survive long.
There are at least an order of magnitude more perceived memory leaks. These result mainly from causes such as:
LV: Is there a list of known memory leaks in either Tcl 8.4 or 8.5? We regularly see people here on the wiki or in comp.lang.tcl which are trying to track down memory leaks. Sometimes, the code is only a dozen lines of code, and so doesn't look like a coding leak...
EKB 20016-03-12: I have two memory-related questions:
Lars H: As I recall it, there are at least two places where compiled regular expressions are stored. One is in the Tcl_Obj, and that goes away when the Tcl_Obj does or changes representation. The other is that the regular expression compiler maintains a cache of recently compiled regexps and their compiled form; I think this cache is limited to 20-or-so elements. I don't know if there are any others. EKB - Thanks!
I ask because I'm debugging a tough memory leak, and these are two prime culprits.
If this is the wrong place to put such questions, please send me to the right place. Thanks!
comp.lang.tcl might be a better place to ask.
DKF: Bindings are indeed released, but there are things in Tk which are not. In particular, window names (not the full names, but just the last component of each name) and canvas and text tags (strictly, anything that is a Tk_Uid) are not deleted ever in Tk 8.4. In 8.5, they are per-thread resources, which will mean that you have to dispose with the thread to get rid of them. (You could argue that this is a highly sucky situation, and I wouldn't disagree.) See Fixing Tk_Uid leaks.
A workaround for this is to reuse the names of these sorts of things as much as you can. Like that, you just have high-water-mark effects instead of total-cumulative effects, meaning that virtually all programs will settle out at a certain level of usage instead of gobbling up ever more.
EKB: Thanks very much. This gives me a lot of promising things to try.
I am working on a leak I found in tk 8.4.6 (oldie but goodie; needed for my production site). Here is the data from valgrind:
==3514== 2,016 bytes in 12 blocks are definitely lost in loss record 140 of 187 ==3514== at 0x40046C1: malloc (vg_replace_malloc.c:149) ==3514== by 0xBFD343: XcursorCursorsCreate (in /usr/X11R6/lib/libXcursor.so.1.0.2) ==3514== by 0xBFE833: XcursorImagesLoadCursors (in /usr/X11R6/lib/libXcursor.so.1.0.2) ==3514== by 0xBFE910: XcursorImagesLoadCursor (in /usr/X11R6/lib/libXcursor.so.1.0.2) ==3514== by 0xC016DE: XcursorTryShapeCursor (in /usr/X11R6/lib/libXcursor.so.1.0.2) ==3514== by 0x86AD76: XCreateGlyphCursor (in /usr/X11R6/lib/libX11.so.6.2) ==3514== by 0x8826B73: TkGetCursorByName (tkUnixCursor.c:225) ==3514== by 0x8814D79: TkcGetCursor (tkCursor.c:261) ==3514== by 0x8814C37: Tk_AllocCursorFromObj (tkCursor.c:153) ==3514== by 0x88124C1: DoObjConfig (tkConfig.c:873) ==3514== by 0x8812C11: Tk_SetOptions (tkConfig.c:1358) ==3514== by 0x87A2267: ConfigureFrame (tkFrame.c:949)
Best I can tell, the problem is that when the configuration options are freed, it's not calling Tk_FreeCursorFromObj().
A perusal of the latest tk release didn't yield any insights. Anybody know about this one?