#1139 leak related to SOURCE command

obsolete: 8.2
closed-invalid
nobody
2
2001-04-18
2000-10-26
Anonymous
No

OriginalBugID: 4552 Bug
Version: 8.2
SubmitDate: '2000-03-24'
LastModified: '2000-03-27'
Severity: LOW
Status: Released
Submitter: techsupp
ChangedBy: hobbs
OS: Windows NT
FixedDate: '2000-03-27'
FixedInVersion: 8.3.1
ClosedDate: '2000-10-25'

Name:
Kent Bloomstrand

ReproducibleScript:
The leak is not limited to only the TclPro library. I just ran
another test this morning against both the "tcl82.dll" that
ships with SS 5.0 and that of Tcl 8.2.3 and here is what I found:

Beside the TclPro 1.3 tbcload leak problem, there is a definite leak
in the base "source" command not getting properly cleaned up after
TCL_DeleteInterp() is called. This happens with either the "tcl82.dll"
that ships with StoryServer 5.0 (w/ 5.0.1 QA-8 patch) or with the
Tcl 8.2.3 "tcl82.dll". I don't think we can allow leaks like this to
occur in our products.

In a simple test case, I run the program below to simulate a total
of 40000 calls to repeatedly "source" the same non-compiled TCL file
(with 600 simple procedures inside) and the total leak was about 10MB
on my NT box.

How to reproduce:
Compile and run the following C program (similar to the one from Step 3).
The file "d:/temp/plain.tcl" (cmd_2 in the following program) is the
same simple TCL file from Step 1 before with 600 simple procedures
such as 'proc ::ns::proc_a {} {return 1}':

int main(int argc, char* argv[])
{
int i, j, status;
char *cmd_2 = "source {d:/temp/plain.tcl}";
Tcl_Interp *interp;

interp = Tcl_CreateInterp();
for (i = 0 ; i < 400 ; i++) {
printf("%d...", i);
for (j = 0 ; j < 100 ; j++) {
printf(".");
status = Tcl_GlobalEval(interp, cmd_2);
if (status != TCL_OK) {
printf("Source failed\n");
return 1;
}
}
printf("\n");
}
Tcl_DeleteInterp(interp);

printf("Hit RETURN when done...");
getchar();
return 0;
}

ObservedBehavior:
it leaks memory

DesiredBehavior:
it doesn't leak

This turned out to be a "bug" in the provided script which never
cleared the namespace export array (given the optional -clear
argument). 8.3.1 has a fix to further improve this by checking
for duplicates before adding to the export array.
-- 03/27/2000 hobbs

Discussion

  • Brent B. Welch

    Brent B. Welch - 2000-10-26
    • priority: 5 --> 2
    • status: open --> closed-fixed
     
  • Don Porter

    Don Porter - 2001-04-18
    • labels: 104246 --> 21. [namespace]
    • status: closed-fixed --> closed-invalid
     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks