[Tcl-bugs] [ tcl-Bugs-467523 ] memory leak in [namespace eval foo {}]

[<no...@so...>]

Bugs item #467523, was opened at 2001-10-03 08:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=110894&aid=467523&group_id=10894

Category: 44. Bytecode Compiler
Group: 8.4a3
>Status: Open
Resolution: Fixed
>Priority: 8
Submitted By: Ronnie Brunner (rbrunner)
Assigned to: miguel sofer (msofer)
Summary: memory leak in [namespace eval foo {}]

Initial Comment:
The following code leaks (in every Tcl version):

  interp create foo 
  foo eval {
      namespace eval bar {}
  }
  interp delete foo

Note: 

  interp create foo 
  foo eval {
      namespace eval bar {\#}
  }
  interp delete foo

does NOT leak.

Unfortunately I didn't really track down the problem, 
but the call 

  result = Tcl_EvalObjEx(interp, objv[3], 0);

in generic/tclNamesp.c line 2955 (tcl8.4.a3), which is 
called with an empty string in objv[3] seems to cause 
the leak. Changing this code to 

  if (strlen(Tcl_GetString(objv[3])))
    result = Tcl_EvalObjEx(interp, objv[3], 0);
  else
    result = TCL_OK;

fixes the symptoms, but certainly not the problem.
(Sorry for not having a proper fix.)

----------------------------------------------------------------------

>Comment By: miguel sofer (msofer)
Date: 2001-10-09 09:02

Message:
Logged In: YES 
user_id=148712

Ronnie: Yes, the patch only adds one loc to tclLiteral.c

I do not see any problems with that code in either 8.4a3,
8.4a4 or the 8-3-1-branch code - your script does not
trigger a dump on my setup.

Could you help me reproduce the dump? I'd need to know 
  - configure and compile flags
  - how you are running the script: tclsh? tkcon? from a
file?
  - anything else?

Thanks

----------------------------------------------------------------------

Comment By: Ronnie Brunner (rbrunner)
Date: 2001-10-09 08:39

Message:
Logged In: YES 
user_id=205230

Miguel: did you only patch tclLiteral.c? Compiling with the 
latest version of this file (1.9, same as 1.8.2.1) tcl8.4a3 
crashes running the following code:

for {set a 0} {$a < 10} {incr a} {
    namespace eval bar {}
    namespace delete bar
}

my tclsh dumps core with

  file = ./../generic/tclExecute.c, line = 663
  Trying to increment refCount of previously disposed 
object.
  Abort (core dumped)


----------------------------------------------------------------------

Comment By: miguel sofer (msofer)
Date: 2001-10-05 18:05

Message:
Logged In: YES 
user_id=148712

Patch committed to HEAD and core-8-3-1-branch

----------------------------------------------------------------------

Comment By: miguel sofer (msofer)
Date: 2001-10-05 17:02

Message:
Logged In: YES 
user_id=148712

The attached leak.patch to generic/tclLiteral.c
(TclReleaseLiteral) solves the issue.

----------------------------------------------------------------------

Comment By: miguel sofer (msofer)
Date: 2001-10-05 06:37

Message:
Logged In: YES 
user_id=148712

The problem (I think) is that the object referred to by the
literal "" in the slave interp is never freed, as it is
self-referential: the bytecode pushes itself on the stack,
so that the bytecode object always has refCount >=1 - it
appears in its own local literal table. 

The code leaks 164 bytes: 24 for the object, 128 for its
internal rep as a bytecode, 12 for the handle to the
interpreter (it would be freed by CleanupByteCode when the
object is freed).

One possible solution I am exploring is to be more careful
about sharing literals. The solution to this bug along this
path could conceivably also fix [Bug 458361] in a roundabout
way.



----------------------------------------------------------------------

Comment By: Ronnie Brunner (rbrunner)
Date: 2001-10-04 12:27

Message:
Logged In: YES 
user_id=205230

Some further observations:
Any recursive call to Tcl_EvalObjEx with an empty string 
object to eval leaks:

  time {time {}}
  time {switch 1 1 {}}
  switch 1 1 {time {}}

In addition I found out, that these calls leak, whenever 
the innermost empty code matches the Literal that is added 
in TclCompile.c line 1041 (tcl8.4a3):

  TclRegisterLiteral(envPtr, "", 0, /*onHeap*/ 0)

Setting this to

  TclRegisterLiteral(envPtr, "  ", 2, /*onHeap*/ 0)

makes 

  time {time {  }}

leak. It seems that this equality increments the empty 
codes object's refCount (objPtr in Tcl_evalObjEx) to be too 
high -> it is not cleaned up properly.


----------------------------------------------------------------------

Comment By: miguel sofer (msofer)
Date: 2001-10-03 12:12

Message:
Logged In: YES 
user_id=148712

No, that wasn't it ...

----------------------------------------------------------------------

Comment By: miguel sofer (msofer)
Date: 2001-10-03 10:16

Message:
Logged In: YES 
user_id=148712

I think the leak should occur at any evaluation of {}, ie,
also for
    proc a {} {}
    a

As I see it, the special handling of "bytecodes with empty
source" in Tcl_EvalObjEx is at fault. I enclose a small
patch that should correct this.

Ronnie, Jeff: does this fix the bug?
  

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2001-10-03 09:43

Message:
Logged In: YES 
user_id=72656

Confirmed in 8.3.3.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=110894&aid=467523&group_id=10894