Tcl Source Code

View Ticket
Login
Ticket UUID: 1504500
Title: slave interp evaluation leaks memory
Type: Bug Version: None
Submitter: eriklns Created on: 2006-06-11 21:57:07
Subsystem: 41. Memory Allocation Assigned To: hobbs
Priority: 5 Medium Severity:
Status: Closed Last Modified: 2006-06-27 09:20:29
Resolution: Invalid Closed By: sf-robot
    Closed on: 2006-06-27 02:20:29
Description:
When an arbitrary script is evaluated by a slave
interpreter, memory leaks according to valgrind.

Attached you find two files used to reproduce this leak:
- memtest
  This executable shell script drives the test.
  It runs tclsh (under valgrind) with a scriptfile
argument, redirecting stderr to valgrind.out
- memtest.tcl
  The Tcl script evaluating an arbitrary script in a
slave interp

The file valgrind.out holds the findings of valgrind
run on my computer, using Linux, Tcl8.4.13
User Comments: sf-robot added on 2006-06-27 09:20:29:
Logged In: YES 
user_id=1312539

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

eriklns added on 2006-06-12 16:47:35:
Logged In: YES 
user_id=113903

Last comment was by Erik Leunissen not being logged in.

nobody added on 2006-06-12 16:39:56:
Logged In: NO 

I was only focused on the leak which was categorized as
"definitely lost" in valgrinds output (you attributed that
one to the stdout channel).

I tested it again under valgrind with some 10 cycles (as you
indicated), and you are right: valgrind reports the same
leak with the same size as in the case of a single cycle. So
indeed, this must be a one time memory leak.

I understand that this leak is purposely left for the OS to
clean up ... OK, no more questions for me.

msofer added on 2006-06-12 05:53:40:
Logged In: YES 
user_id=148712

I do not see any *real* leak there. Tcl does leave some
memory to be cleaned by the os on exit, and that is what you
are seeing. In this case, the main interp's execution
environment and the stdout channel.

In order to test real leaks in slave interps, you may try to
run the following in a shell, checking the memory reqs with
top in a different shell:

while 1 {
   interp create slave
   slave eval {
       # whatever you want here; note that writing
       # to the console will increase the corresponding
       # memory reqs until the scrollback buffer is full
   }
   interp delete slave
}

If there is a leak, the memory should keep increasing. It
doesn't here.

Assigning to hobbs for a second opinion.

eriklns added on 2006-06-12 04:58:24:

File Added - 181336: valgrind.out

eriklns added on 2006-06-12 04:57:37:

File Added - 181335: memtest.tcl

eriklns added on 2006-06-12 04:57:08:

File Added - 181334: memtest

Attachments: