From: SourceForge.net <no...@so...> - 2005-05-31 12:51:47
|
Bugs item #988703, was opened at 2004-07-11 02:07 Message generated for change (Comment added) made by vasiljevic You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=988703&group_id=10894 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 10. Objects Group: current: 8.5a2 Status: Open Resolution: None Priority: 7 Submitted By: Joe Mistachkin (mistachkin) Assigned to: Zoran Vasiljevic (vasiljevic) Summary: tsdPtr->objThreadMap and data never freed in tclObj.c Initial Comment: 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? ---------------------------------------------------------------------- >Comment By: Zoran Vasiljevic (vasiljevic) Date: 2005-05-31 14:51 Message: 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. ---------------------------------------------------------------------- Comment By: Joe Mistachkin (mistachkin) Date: 2004-07-14 04:09 Message: 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"? ---------------------------------------------------------------------- Comment By: Joe Mistachkin (mistachkin) Date: 2004-07-14 01:41 Message: 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. ---------------------------------------------------------------------- Comment By: miguel sofer (msofer) Date: 2004-07-13 23:41 Message: Logged In: YES user_id=148712 Dropping the ball: I don't know about these issues. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=988703&group_id=10894 |