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 |