For Programmers: Free Programming Magazines  


Home > Archive > Tcl > December 2006 > Re: Tcl_DumpActiveMemory and tk









You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

 

Author Re: Tcl_DumpActiveMemory and tk
Donal K. Fellows

2006-12-24, 7:10 pm

danl@dropzone.com wrote:
> I run wish, and close the tk window, which closes wish. The dump file
> contains 2528 lines,
> e29cc0 - e29d27 104 @ ..\generic\tkEvent.c 1333
> cffd88 - cffdef 104 @ ..\generic\tkEvent.c 1333
> d88048 - d880af 104 @ ..\generic\tkEvent.c 1333
> db26f0 - db2757 104 @ ..\generic\tkEvent.c 1333
> dc54e0 - dc5547 104 @ ..\generic\tkEvent.c 1333


This should not be a real memory leak; it's just events that have not
quite finished being handled yet. If you drain Tcl's event queue fully
after returning from Tk_MainLoop() but before deleting the interpreter,
they should go away (I think...)

(The memory allocated should be freed in the guts of Tcl's notifier code
inside Tcl_ServiceEvent(), if I've read this right.)

> bad1e8 - bad1eb 4 @ ..\generic\tclThread.c 107
> e21668 - e2167f 24 @ ..\generic\tclThread.c 107


That's memory that is not released until you finalize the whole library
with Tcl_Finalize(). It shouldn't be a concern.

> 386c48 - 386c62 27 @ ..\generic\tclHash.c 937
> 386bc8 - 386bde 23 @ ..\generic\tclHash.c 937
> 386b40 - 386b59 26 @ ..\generic\tclHash.c 937
> 386ac0 - 386ad7 24 @ ..\generic\tclHash.c 937


Hmm, that's from a hash table somewhere, but I've no idea where that
hash was allocated from. Might be a leak, but might not. Depends on who
allocated the container, which is information that is lost...

> Are these real memory leaks? Am I doing something wrong or neglecting
> to do something?


Some of them are *possibly* memory leaks (you'll need to use a more
advanced tool to figure out if they are or not) but the rest are things
that are just due to incomplete teardown of the application. Of course,
if you're about to exit, none of this matters as the OS automatically
reclaims all memory when the process goes away. :-)

Only worry about memory leaks if you detect the size of a process
increasing as your program runs (using a tool like 'top' of course, or
the 'VM Size' column in the Windows Task Manager). If you can't measure
a memory leak, it's not worth trying to squelch it.

Donal.
Sponsored Links







Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive

Copyright 2008 codecomments.com