Tcl Source Code

View Ticket
Login
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: