Ticket UUID: | 994838 | |||
Title: | memory leak in interpreter creation/deletion loop | |||
Type: | Bug | Version: | obsolete: 8.5a2 | |
Submitter: | kennykb | Created on: | 2004-07-20 21:45:45 | |
Subsystem: | 47. Bytecode Compiler | Assigned To: | kennykb | |
Priority: | 7 High | Severity: | ||
Status: | Closed | Last Modified: | 2011-05-11 11:16:15 | |
Resolution: | Fixed | Closed By: | msofer | |
Closed on: | 2004-07-23 18:40:27 | |||
Description: |
Running the loop while 1 { interp create i interp delete i } results in process memory growing endlessly. Miguel Sofer and I have been discussing the bug at length in email and the Tcl'ers Chat and have reached the conclusion that the problem arises when a proc's bytecode representation lives until the interp is deleted (generally, because some shared literal has an internal representation of tclLocalVarType that designates a variable in the proc). I now suspect that the problem is ameliorated if internal representations of global literals are destroyed earlier in the process of taking down an interp. I'm developing a patch to test this hypothesis. | |||
User Comments: |
kennykb added on 2011-05-11 11:16:15:
Agreed. It was a hack to deal with circular Tcl_Obj references. Miguel fixed the circular references. It can go. msofer added on 2011-05-11 01:15:50: Agreed: remove dgp added on 2011-05-11 00:54:37: Yes, kbk did that to fix (work around?) a leak tearing down interps. Then you fixed the underlying cause shortly afterward. http://core.tcl.tk/tcl/info/63de804c96 After that, TclCleanupLiteralTable() can be removed. I'd like to do so. Why have code you don't need? But I want to know what others think. Are we keeping it around just as another layer of protection in case another similar bug pops up? msofer added on 2011-05-08 22:34:17: kbk's fix for [Bug 994838]. See http://core.tcl.tk/tcl/info/460aa80311bfa1259a4562d35e5a40558e9a019d msofer added on 2011-04-26 09:30:01: Chatlogs: dgpFor when I get back, I'm curious about the purpose of TclCleanupLiteralTable(). kbkdgp - ISTR that the literal table is one case where it's possible that Tcl_Obj's' int-reps can hold references to each other, and that a bespoke cleanup was needed to break cycles and actually kill them, but I may dgphere's my observations dgpTCLT() is called in only one place, DeleteInterpProc(.) in tclBasic.c dgpAbout 100 lines later in the same DIP(.) routine, TclDeleteLiteralTable() is called. dgpTCLT only removes intreps of literal values. dgpTDLT actually frees them, which would destroy intreps if any were still around. dgpThe value of the TCLT pass is not clear to me. dgpCommenting it out has no effect on the success of the test suite. dgphmmm, TCLT is not in Tcl 8.4, so the history of its origin ought to be findable.... dgp added on 2011-04-26 03:26:00: Miguel, can you comment on what importance the call to TclCleanupLiteralTable() still has? msofer added on 2004-07-24 01:40:27: Logged In: YES user_id=148712 Committed a change in tclLocalVarnameType that removes the reference to the proc, and hence renders these circular references impossible. Closing the ticket, the bug is now fixed twice over ;) msofer added on 2004-07-21 17:35:20: Logged In: YES user_id=148712 The patch has been committed, ticket still open until I reach a full understanding of the issue and am satisfied of its correction and completeness. Issues: (0) I still do not see why the leak was only observable in windows. (1) it frees the internal rep of every shared literal, but unshared literals are not covered. This will break any reference loop where a shared literal intervenes, but leaves the issue untouched for loops of unshared lits (2) it panics on a literal with no string rep; this can only occur with unshared literals created via TclAddLiteralObj(), so it is not really an issue while issue (1) remains untouched kennykb added on 2004-07-21 04:57:27: File Added - 94620: litTable.patch kennykb added on 2004-07-21 04:57:26: Logged In: YES user_id=99768 The attached patch appears to correct the problem as described. |
Attachments:
- litTable.patch [download] added by kennykb on 2004-07-21 04:57:27. [details]