Tcl Source Code

This ticket created temporarily as a holding place for the valgrind reports, until the different problems re assigned to the correct maintainer.

Attached the error and leak reports. There are 14 different leaks and 18 different errors, where "different" means that they do not coincide in a stack trace of depth 10.

Logged In: YES 
user_id=99768
Originator: NO

Now that we are down to no errors and a manageable number of leaks,
I'm closing this report and opening separate bugs to track the individual
leaks that remain.  Refer to Bugs 1710707, 1710709 and 1710710.

File Added - 226656: kevinleaks4.txt

Logged In: YES 
user_id=99768
Originator: NO

List of leaks updated again. kevinleaks4.txt
File Added: kevinleaks4.txt

Logged In: YES 
user_id=148712
Originator: YES

(kevinleaks3.txt seems to repeat itself)

[K15], [K15a] and [K21] (tclProc.c:1439) seem to point to Tcl_WrongNumArgs: the only place those objs are going before being decrRefCounted at line 1463.

File Added - 226503: kevinleaks3.txt

Logged In: YES 
user_id=99768
Originator: NO

The 'kevinleaks3.txt' file is the latest round.  It adds leaks detected in subprocesses of exec.test and tcltest.test.  It also reflects that K03, K04, K05, K06, K07, K13, K14, and K17 have all been corrected.  
File Added: kevinleaks3.txt

Logged In: YES 
user_id=99768
Originator: NO

The latest changes to tclNamesp.c appear to fix K03 and K03a in kevinleaks1.tcl

Logged In: YES 
user_id=99768
Originator: NO

Uploaded another catalog of leaks, kevinleaks1.txt
File Added: kevinleaks1.txt

File Added - 226428: kevinleaks1.txt

Logged In: YES 
user_id=99768
Originator: NO

The test, 'namespace-7.7' reports the following leak:
==3773== 268 (264 direct, 4 indirect) bytes in 1 blocks are definitely lost in loss record 1,560 of 1,841
==3773==    at 0x401A846: malloc (vg_replace_malloc.c:149)
==3773==    by 0x8134795: TclpAlloc (tclAlloc.c:710)
==3773==    by 0x806BCF5: Tcl_Alloc (tclCkalloc.c:1019)
==3773==    by 0x80E1DA1: Tcl_CreateNamespace (tclNamesp.c:813)
==3773==    by 0x80621B0: Tcl_CreateInterp (tclBasic.c:443)
==3773==    by 0x80C52D6: SlaveCreate (tclInterp.c:2146)
==3773==    by 0x80C335D: Tcl_InterpObjCmd (tclInterp.c:700)
==3773==    by 0x80659C6: TclEvalObjvInternal (tclBasic.c:3617)
==3773==    by 0x8066947: TclEvalEx (tclBasic.c:4221)
==3773==    by 0x8065DFC: Tcl_EvalEx (tclBasic.c:3892)

File Added - 226366: results2.gz

Logged In: YES 
user_id=148712
Originator: YES

File Added: results2.gz

File Added - 226365: results2.errors

Logged In: YES 
user_id=148712
Originator: YES

File Added: results2.errors

File Added - 226364: results2.leaks

Logged In: YES 
user_id=148712
Originator: YES

Attached result2 from last night's run (missing kevin's overnight fixes, not all reports current I guess). All errors seem to be at the os level, and related to the way I am running the tests.

I did mark the old leak numbers next to the new for reference.
File Added: results2.leaks

Logged In: YES 
user_id=99768
Originator: NO

One leak relates to the 'args' argument to a variadic procedure.
The argument is not leaked consistently.  In testing ioCmd.test,
I discovered that the first test case leaking 'args' is
ioCmd-21.8.

The direct leak does not appear to be 'args', however; it's

==30055== 26 (24 direct, 2 indirect) bytes in 1 blocks are definitely lost in loss record 2 of 5
==30055==    at 0x401B6FE: malloc (vg_replace_malloc.c:149)
==30055==    by 0x4042029: TclpAlloc (tclAlloc.c:710)
==30055==    by 0x404C3D1: Tcl_Alloc (tclCkalloc.c:1019)
==30055==    by 0x40BF8D4: TclRegisterLiteral (tclLiteral.c:348)
==30055==    by 0x407F890: TclCompileTokens (tclCompile.c:1840)
==30055==    by 0x406DB4B: TclCompileReturnCmd (tclCompCmds.c:3149)
==30055==    by 0x407E1B3: TclCompileScript (tclCompile.c:1525)
==30055==    by 0x407C669: TclSetByteCodeFromAny (tclCompile.c:493)
==30055==    by 0x407C858: SetByteCodeFromAny (tclCompile.c:588)
==30055==    by 0x40DCCAE: ProcCompileProc (tclProc.c:1781)
==30055==    by 0x40DC117: ObjInterpProcEx (tclProc.c:1237)
==30055==    by 0x40DC015: TclObjInterpProc (tclProc.c:1199)

which is rather a different spot than what we've seen up to now.
I suspect that there is a more subtle memory mismanagement issue
that causes the apparent leak to be a Heisenbug.

Logged In: YES 
user_id=99768
Originator: NO

Putative fixes for leaks #2, #4, and #13 committed.

Logged In: YES 
user_id=75003
Originator: NO

Ah. Reading over the code (tclExecute.c) I have to confirm. That is a path I had not seen. Thank you for finding and fixing it. The change you made definitely fixes that problem. Accepted.

Logged In: YES 
user_id=148712
Originator: YES

Andreas: it was being leaked on error exit from Tcl_ExprObj (at line 824, before the transfer atline 844). The leak is really fixed now - at least as far as valgrind is concerned.

Logged In: YES 
user_id=75003
Originator: NO

Miguel, the extCmdMapPtr leak is troublesome. The pointer is allocated in line 883, and while there was no code releasing it in "TclFreeCompileEnv" your change to it (line 997) should have no effect, this code should never be executed. Because in line 2200 the pointer is transfered to a different structure, the "lineBCPtr"-Tcl_HashTable in the Interp* structure. The pointer in the compile environment is set to NULL at that point. The lineBCPtr hash is allocated in line 390 of "tclBasic.c". Release of elements happens in either lines 1310ff of the same file, or in "TclCleanupByteCode", in file "tclCompile.c", line 785ff. These are the two places where extCmdMapPtr should be released, as part of the hash entry.

The only way I can see extCmdMapPtr leaking is if the ByteCode of some Tcl code itself is not released.

Logged In: YES 
user_id=99768
Originator: NO

I've committed HEAD fixes that resolve issues 15, 18, 20, 21, 22, 23, 25, 29, 30, 31, 32 in results.errors.  I cannot reproduce issues 16, 17, 19, 24, 26, 27, 28 - all of which appear to be occurring inside ld.so.

Logged In: YES 
user_id=148712
Originator: YES

* generic/tclCompile.c (TclFreeCompileEnv): Tip 280's new fieldextCmdMapPtr was not being freed [Bug 1705778, leak #1].

File Added - 226248: valgrindScripts.tar.gz

Logged In: YES 
user_id=148712
Originator: YES

Attaching the scripts used to produce those files.
File Added: valgrindScripts.tar.gz

Logged In: YES 
user_id=148712
Originator: YES

File Added: results.full.gz

File Added - 226210: results.full.gz

File Added - 226209: results.errors

Logged In: YES 
user_id=148712
Originator: YES

File Added: results.errors

File Added - 226208: results.leaks