Tcl Source Code

When compiled with threads and debugging, the
tsdPtr->objThreadMap hash table and it's associated
data is never freed.  This leak grows for each object
allocated and for each thread used.

A patch designed to fix this issue is attached.

Please review and commit.

Also, I believe this bug may exist in the
core-8-4-branch as well.  Perhaps this bugfix should be
backported?

Now backported to core-8-5-branch.

allow_comments - 1

Committed; not bothering to backport.

There are a few spots where the patch doesn't brace arms of an 'if', but otherwise looks good.

Don't forget to write a bit of documentation. Feel free to do that by writing a short paragraph in here; I'm happy to patch it into docs/memory.n for you.

I could survive changing [memory] without a TIP; it's not a tool that production code will be using (too much of a performance penalty). Indeed, if we were doing it now I bet it would go in tcl::unsupported

File Deleted - 233642: 


Updated patch to HEAD, cleaned up, and added the ability to dump the active
objects.  The patch cannot be committed "as is" without a TIP because it
adds an "objs" sub-command to [memory].  This functionality is extremely
useful for debugging Tcl_Obj leaks; therefore, I'm willing to entertain
alternative approaches on exposing it that could make it into 8.6.

File Added: TclDbInitNewObj.zip

File Added - 317876: TclDbInitNewObj.zip

File Added - 233642: objThreadMap3.diff

Logged In: YES 
user_id=113501
Originator: YES


Here is the updated and tested patch against HEAD.  It corrects the leak(s) and enhances the objThreadMap to track file and line information per object when TCL_THREADS and TCL_MEM_DEBUG are enabled.  With this patch, the threaded debug build (on Windows) now leaks zero bytes.

File Added: objThreadMap3.diff

File Deleted - 93877:

Logged In: YES 
user_id=95086

As I see, the core-8-4-branch does not track the debugging info
about objects created in a thread, hence there is nothing to backport.

Yes, it seems that this table is never garbage collected and this will
result in memory leaks with debugging turned on. It is therefore
correct to garbage-collect this table on thread exit. I do not think that
we should ask ourselves about this being the "right thing". If the table
is allocated, it must be garbage collected, regardless how or from whom
it got created and/or under which circumstances. 

I will have to study this in some more detail because this is the first
time I'm looking at that code, It must have beed added lately and I 
have obviously missed that.

Do you see any particular hidden danger here. I do not at the first 
glance.

File Added - 93877: bug988703.diff

Logged In: YES 
user_id=113501


Patch updated. Although, now that I think about it, I'm not
sure what the "right thing" is in this case.  Can people
create a new Tcl_Obj without hitting the code that
initializes the thread storage for "tclEvent.c"?

File Deleted - 93512:

Logged In: YES 
user_id=113501


Patch needs to be update, the call:

  TclFinalizeThreadObjDebugging();

needs to be outside of the "if" block it is currently in.

Logged In: YES 
user_id=148712

Dropping the ball: I don't know about these issues.

File Added - 93512: bugfix.diff