See Also edit
- memory leak finding with memory trace
- Why Do Programs Take Up So Much Memory ?
- How to debug memory faults in Tcl and extensions
- Memory introspection
- Measuring memory usage
- Memory Footprint Comparisons
- Memory costs with Tcl
- Memory used by tcl script, comp.lang.tcl, 2004-05-07
- tclguy mentions Tcl's own memory allocator with its high-water marking.
- Memory problem, comp.lang.tcl, 2003-10-14
- tclguy mentions the Tcl_Obj pool, and that memory is held at the high water mark if you use a threaded build, which has its own memory allocator, or you specifically use the internal Tcl allocator.
Description editThere are at least an order of magnitude more perceived memory leaks. These result mainly from causes such as:
- Mis-measured memory use.
- Userland, or application-level, memory leaks.
- System or underlying language libraries (like libc for the C * implementation of Tcl).
- photo images created and not deleted, though never ever used * (arguably, this is a kind of userland memory leak).
- Files have been opened but not closed - check file channels to see * them.
Discussion editLV: 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:
- Are compiled regular expressions released from memory? If they are, at what point does this happen? (And if not, can I call them up again without recompiling them?)
- Are bindings for a window released from memory when the window is destroyed?
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?