Attachment "kevinleaks3.txt" to
ticket [1705778fff]
added by
kennykb
2007-04-25 10:09:50.
The bugs formerly identified by [K03], [K04], [K05], [K06], [K07],
[K13], [K14], [K17], have all been fixed. Here is a more-or-less
up-to-date set of the remaining leaks. Note that many are likely
symptoms of the same underlying problem, particularly K01 and K02
in all their many manifestations.
[K01] The commentary in the source states that TclpGetNativeCwd
transfers ownership of the returned memory to the caller.
Nevertheless, removing the duplication gives a pointer smash.
This leak shows up in most test runs.
==23806== 67 bytes in 2 blocks are definitely lost in loss record 1,649 of 2,871
==23806== at 0x401A846: malloc (vg_replace_malloc.c:149)
==23806== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==23806== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==23806== by 0x410FBBF: TclpGetNativeCwd (tclUnixFile.c:705)
==23806== by 0x40C59FA: Tcl_FSChdir (tclIOUtil.c:2980)
==23806== by 0x404CF17: Tcl_CdObjCmd (tclCmdAH.c:332)
==23806== by 0x4091D0C: TclExecuteByteCode (tclExecute.c:1834)
==23806== by 0x408F8EF: TclCompEvalObj (tclExecute.c:996)
==23806== by 0x40E758A: TclObjInterpProcCore (tclProc.c:1517)
==23806== by 0x40E6E25: ObjInterpProcEx (tclProc.c:1269)
[K02] This one also appears in a great many test runs.
==23806== 151 (24 direct, 127 indirect) bytes in 1 blocks are definitely lost in loss record 1,937 of 2,871
==23806== at 0x401A846: malloc (vg_replace_malloc.c:149)
==23806== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==23806== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==23806== by 0x40ED206: Tcl_NewStringObj (tclStringObj.c:210)
==23806== by 0x40DC630: TclFSNormalizeAbsolutePath (tclPathObj.c:235)
==23806== by 0x40DEE09: Tcl_FSGetNormalizedPath (tclPathObj.c:1920)
==23806== by 0x40C472D: Tcl_FSEvalFileEx (tclIOUtil.c:1757)
==23806== by 0x405969D: Tcl_SourceObjCmd (tclCmdMZ.c:953)
==23806== by 0x4091D0C: TclExecuteByteCode (tclExecute.c:1834)
==23806== by 0x408F8EF: TclCompEvalObj (tclExecute.c:996)
[K01a] This one is the same as [K01] but called from direct eval
rather than compiled code.
==23806== 288 bytes in 8 blocks are definitely lost in loss record 2,451 of 2,871
==23806== at 0x401A846: malloc (vg_replace_malloc.c:149)
==23806== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==23806== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==23806== by 0x410FBBF: TclpGetNativeCwd (tclUnixFile.c:705)
==23806== by 0x40C59FA: Tcl_FSChdir (tclIOUtil.c:2980)
==23806== by 0x404CF17: Tcl_CdObjCmd (tclCmdAH.c:332)
==23806== by 0x40441E5: TclEvalObjvInternal (tclBasic.c:3617)
==23806== by 0x404516F: TclEvalEx (tclBasic.c:4221)
==23806== by 0x404461B: Tcl_EvalEx (tclBasic.c:3892)
==23806== by 0x404585E: TclEvalObjEx (tclBasic.c:4592)
[K15] This hasn't been isolated except that it is known to fail in
[mnopq]*.test:
==24120== 24 bytes in 1 blocks are definitely lost in loss record 1,017 of 4,124
==24120== at 0x401A846: malloc (vg_replace_malloc.c:149)
==24120== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==24120== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==24120== by 0x40E7169: TclObjInterpProcCore (tclProc.c:1439)
==24120== by 0x40E6E25: ObjInterpProcEx (tclProc.c:1269)
==24120== by 0x40E6CA1: TclObjInterpProc (tclProc.c:1199)
==24120== by 0x40441E5: TclEvalObjvInternal (tclBasic.c:3617)
==24120== by 0x4044426: Tcl_EvalObjv (tclBasic.c:3737)
==24120== by 0x40D48A1: NsEnsembleImplementationCmd (tclNamesp.c:6243)
==24120== by 0x40441E5: TclEvalObjvInternal (tclBasic.c:3617)
[K20] Another VFS one, not yet isolated to a test case.
==24120== 72 (28 direct, 44 indirect) bytes in 1 blocks are definitely lost in loss record 1,761 of 4,124
==24120== at 0x401A846: malloc (vg_replace_malloc.c:149)
==24120== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==24120== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==24120== by 0x40DF7E9: SetFsPathFromAny (tclPathObj.c:2428)
==24120== by 0x40DF1D5: TclFSSetPathDetails (tclPathObj.c:2162)
==24120== by 0x40C6C9A: Tcl_FSGetFileSystemForPath (tclIOUtil.c:4432)
==24120== by 0x40C3C5D: Tcl_FSMatchInDirectory (tclIOUtil.c:1093)
==24120== by 0x80575FD: SimpleMatchInDirectory (tclTest.c:6809)
==24120== by 0x40C3CAE: Tcl_FSMatchInDirectory (tclIOUtil.c:1108)
==24120== by 0x40AC8EF: DoGlob (tclFileName.c:2456)
[K21] I haven't seen this one before, need to find a test case. It
shows up in a subprocess launched from tcltest.test
==24120== 48 bytes in 2 blocks are definitely lost in loss record 1,922 of 4,124
==24120== at 0x401A846: malloc (vg_replace_malloc.c:149)
==24120== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==24120== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==24120== by 0x40E7169: TclObjInterpProcCore (tclProc.c:1439)
==24120== by 0x40E6E25: ObjInterpProcEx (tclProc.c:1269)
==24120== by 0x40E6CA1: TclObjInterpProc (tclProc.c:1199)
==24120== by 0x4091D0C: TclExecuteByteCode (tclExecute.c:1834)
==24120== by 0x408F8EF: TclCompEvalObj (tclExecute.c:996)
==24120== by 0x40459F1: TclEvalObjEx (tclBasic.c:4677)
==24120== by 0x404CCD1: Tcl_CatchObjCmd (tclCmdAH.c:253)
[K22] I haven't seen this one before, need to find a test case. It
shows up in a subprocess launched from tcltest.test
==24120== 55 bytes in 1 blocks are possibly lost in loss record 1,965 of 4,124
==24120== at 0x401A846: malloc (vg_replace_malloc.c:149)
==24120== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==24120== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==24120== by 0x41102C1: TclNativeCreateNativeRep (tclUnixFile.c:1102)
==24120== by 0x40DF0A1: Tcl_FSGetInternalRep (tclPathObj.c:2062)
==24120== by 0x40C6CE4: Tcl_FSGetNativePath (tclIOUtil.c:4475)
==24120== by 0x410FD4E: TclpObjStat (tclUnixFile.c:825)
==24120== by 0x40C4BD1: Tcl_FSStat (tclIOUtil.c:2021)
==24120== by 0x40C476C: Tcl_FSEvalFileEx (tclIOUtil.c:1765)
==24120== by 0x405969D: Tcl_SourceObjCmd (tclCmdMZ.c:953)
[K23] This also shows up in tcltest.test. dgp offered a patch that
fixed most instances with this stack trace - obviously, we have one or
more left over.
==24120== 133 (120 direct, 13 indirect) bytes in 5 blocks are definitely lost in loss record 2,199 of 4,124
==24120== at 0x401A846: malloc (vg_replace_malloc.c:149)
==24120== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==24120== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==24120== by 0x40D6D28: Tcl_NewObj (tclObj.c:689)
==24120== by 0x407854A: ParseLexeme (tclCompExpr.c:2095)
==24120== by 0x4076192: ParseExpr (tclCompExpr.c:284)
==24120== by 0x4078827: TclCompileExpr (tclCompExpr.c:2319)
==24120== by 0x408F250: Tcl_ExprObj (tclExecute.c:788)
==24120== by 0x404D8C5: Tcl_ExprObjCmd (tclCmdAH.c:771)
==24120== by 0x40441E5: TclEvalObjvInternal (tclBasic.c:3617)
[K24] Another new one in the subprocess from tclTest.test.
==24120== 372 (168 direct, 204 indirect) bytes in 6 blocks are definitely lost in loss record 2,362 of 4,124
==24120== at 0x401A846: malloc (vg_replace_malloc.c:149)
==24120== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==24120== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==24120== by 0x40DF7E9: SetFsPathFromAny (tclPathObj.c:2428)
==24120== by 0x40DF1D5: TclFSSetPathDetails (tclPathObj.c:2162)
==24120== by 0x40C6C9A: Tcl_FSGetFileSystemForPath (tclIOUtil.c:4432)
==24120== by 0x40C3C5D: Tcl_FSMatchInDirectory (tclIOUtil.c:1093)
==24120== by 0x80575FD: SimpleMatchInDirectory (tclTest.c:6809)
==24120== by 0x40C3CAE: Tcl_FSMatchInDirectory (tclIOUtil.c:1108)
==24120== by 0x40AC4E2: DoGlob (tclFileName.c:2334)
[K23a] This one looks to be the same case as [K23] but in 'testparser'
rather than in the stock compiler.
==24120== 133 (72 direct, 61 indirect) bytes in 3 blocks are definitely lost in loss record 2,634 of 4,124
==24120== at 0x401A846: malloc (vg_replace_malloc.c:149)
==24120== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==24120== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==24120== by 0x40D6D28: Tcl_NewObj (tclObj.c:689)
==24120== by 0x407854A: ParseLexeme (tclCompExpr.c:2095)
==24120== by 0x4076192: ParseExpr (tclCompExpr.c:284)
==24120== by 0x4078046: Tcl_ParseExpr (tclCompExpr.c:1139)
==24120== by 0x80520B2: TestexprparserObjCmd (tclTest.c:3388)
==24120== by 0x40441E5: TclEvalObjvInternal (tclBasic.c:3617)
==24120== by 0x404516F: TclEvalEx (tclBasic.c:4221)
[K01b] This looks like the same bug as [K01] approached from a
different direction
==24120== 160 bytes in 4 blocks are definitely lost in loss record 2,660 of 4,124
==24120== at 0x401A846: malloc (vg_replace_malloc.c:149)
==24120== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==24120== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==24120== by 0x410FBBF: TclpGetNativeCwd (tclUnixFile.c:705)
==24120== by 0x40C59FA: Tcl_FSChdir (tclIOUtil.c:2980)
==24120== by 0x404CF17: Tcl_CdObjCmd (tclCmdAH.c:332)
==24120== by 0x40441E5: TclEvalObjvInternal (tclBasic.c:3617)
==24120== by 0x404516F: TclEvalEx (tclBasic.c:4221)
==24120== by 0x404461B: Tcl_EvalEx (tclBasic.c:3892)
==24120== by 0x40C4993: Tcl_FSEvalFileEx (tclIOUtil.c:1818)
[K08] This specific trace can show up only with tcltest - and appears
to be a bug in tclTest.c rather than Tcl?
==24120== 296 (144 direct, 152 indirect) bytes in 6 blocks are definitely lost in loss record 2,700 of 4,124
==24120== at 0x401A846: malloc (vg_replace_malloc.c:149)
==24120== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==24120== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==24120== by 0x40ED206: Tcl_NewStringObj (tclStringObj.c:210)
==24120== by 0x8057578: SimpleRedirect (tclTest.c:6778)
==24120== by 0x80575DB: SimpleMatchInDirectory (tclTest.c:6807)
==24120== by 0x40C3CAE: Tcl_FSMatchInDirectory (tclIOUtil.c:1108)
==24120== by 0x40AC4E2: DoGlob (tclFileName.c:2334)
==24120== by 0x40ABB1F: TclGlob (tclFileName.c:1911)
==24120== by 0x40AB38A: Tcl_GlobObjCmd (tclFileName.c:1580)
[K11] Known to fail in [ghi]*.test somewhere
==24120== 168 (24 direct, 144 indirect) bytes in 1 blocks are definitely lost in loss record 2,702 of 4,124
==24120== at 0x401A846: malloc (vg_replace_malloc.c:149)
==24120== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==24120== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==24120== by 0x40ED206: Tcl_NewStringObj (tclStringObj.c:210)
==24120== by 0x40DDA04: Tcl_FSJoinPath (tclPathObj.c:962)
==24120== by 0x40AA054: Tcl_FSJoinToPath (tclFileName.c:793)
==24120== by 0x404DFBD: Tcl_FileObjCmd (tclCmdAH.c:1005)
==24120== by 0x4091D0C: TclExecuteByteCode (tclExecute.c:1834)
==24120== by 0x408F8EF: TclCompEvalObj (tclExecute.c:996)
==24120== by 0x40E758A: TclObjInterpProcCore (tclProc.c:1517)
[K12] This test fails in filesystem-4.0, apparently because the
'simple' file system is leaking a parameter
==24120== 110 bytes in 2 blocks are possibly lost in loss record 2,806 of 4,124
==24120== at 0x401A846: malloc (vg_replace_malloc.c:149)
==24120== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==24120== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==24120== by 0x40ED260: Tcl_NewStringObj (tclStringObj.c:210)
==24120== by 0x40DBF97: TclSubstTokens (tclParse.c:2176)
==24120== by 0x4044AB5: TclEvalEx (tclBasic.c:4086)
==24120== by 0x404461B: Tcl_EvalEx (tclBasic.c:3892)
==24120== by 0x40E1B29: Tcl_PkgRequireProc (tclPkg.c:493)
==24120== by 0x40E2E76: Tcl_PackageObjCmd (tclPkg.c:1013)
==24120== by 0x40441E5: TclEvalObjvInternal (tclBasic.c:3617)
[K12a] Variation on the theme, not seen before (in a subprocess of
tcltest.test)
==24120== 136 (24 direct, 112 indirect) bytes in 1 blocks are definitely lost in loss record 2,816 of 4,124
==24120== at 0x401A846: malloc (vg_replace_malloc.c:149)
==24120== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==24120== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==24120== by 0x40ED206: Tcl_NewStringObj (tclStringObj.c:210)
==24120== by 0x40DBF97: TclSubstTokens (tclParse.c:2176)
==24120== by 0x4044AB5: TclEvalEx (tclBasic.c:4086)
==24120== by 0x404461B: Tcl_EvalEx (tclBasic.c:3892)
==24120== by 0x404585E: TclEvalObjEx (tclBasic.c:4592)
==24120== by 0x40455FE: Tcl_EvalObjEx (tclBasic.c:4475)
==24120== by 0x40E67A4: Tcl_UplevelObjCmd (tclProc.c:889)
[K01c] Again in a subprocess of tcltest.test, looks like the same leak
as in [K01]
==24120== 68 bytes in 2 blocks are definitely lost in loss record 2,828 of 4,124
==24120== at 0x401A846: malloc (vg_replace_malloc.c:149)
==24120== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==24120== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==24120== by 0x410FBBF: TclpGetNativeCwd (tclUnixFile.c:705)
==24120== by 0x40C59FA: Tcl_FSChdir (tclIOUtil.c:2980)
==24120== by 0x40C6B53: Tcl_FSRemoveDirectory (tclIOUtil.c:4347)
==24120== by 0x40A7E1E: TclFileDeleteCmd (tclFCmd.c:392)
==24120== by 0x404DCAD: Tcl_FileObjCmd (tclCmdAH.c:918)
==24120== by 0x4091D0C: TclExecuteByteCode (tclExecute.c:1834)
==24120== by 0x408F8EF: TclCompEvalObj (tclExecute.c:996)
[K01d] Another variation in tcltest.test, this time from within a
[namespace eval]
==24120== 152 bytes in 4 blocks are definitely lost in loss record 2,952 of 4,124
==24120== at 0x401A846: malloc (vg_replace_malloc.c:149)
==24120== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==24120== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==24120== by 0x410FBBF: TclpGetNativeCwd (tclUnixFile.c:705)
==24120== by 0x40C59FA: Tcl_FSChdir (tclIOUtil.c:2980)
==24120== by 0x404CF17: Tcl_CdObjCmd (tclCmdAH.c:332)
==24120== by 0x4091D0C: TclExecuteByteCode (tclExecute.c:1834)
==24120== by 0x408F8EF: TclCompEvalObj (tclExecute.c:996)
==24120== by 0x40459F1: TclEvalObjEx (tclBasic.c:4677)
==24120== by 0x40D0EC5: NamespaceEvalCmd (tclNamesp.c:3472)
[K10] This one turns up in filesystem-4.0, and in a subprocess of
tcltest.test. The culprit is that one of the filesystem calls is
unbalancing the refcount on a parameter.
==24120== 162 (24 direct, 138 indirect) bytes in 1 blocks are definitely lost in loss record 2,954 of 4,124
==24120== at 0x401A846: malloc (vg_replace_malloc.c:149)
==24120== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==24120== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==24120== by 0x40ED206: Tcl_NewStringObj (tclStringObj.c:210)
==24120== by 0x40DBF97: TclSubstTokens (tclParse.c:2176)
==24120== by 0x4044AB5: TclEvalEx (tclBasic.c:4086)
==24120== by 0x404461B: Tcl_EvalEx (tclBasic.c:3892)
==24120== by 0x40E1B29: Tcl_PkgRequireProc (tclPkg.c:493)
==24120== by 0x40E2E76: Tcl_PackageObjCmd (tclPkg.c:1013)
==24120== by 0x4091D0C: TclExecuteByteCode (tclExecute.c:1834)
[K24] In a subprocess of tcltest.test - no idea what's going on there.
==24120== 136 (24 direct, 112 indirect) bytes in 1 blocks are definitely lost in loss record 3,061 of 4,124
==24120== at 0x401A846: malloc (vg_replace_malloc.c:149)
==24120== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==24120== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==24120== by 0x40C9E04: TclRegisterLiteral (tclLiteral.c:348)
==24120== by 0x407DED9: TclCompileTokens (tclCompile.c:1840)
==24120== by 0x407C3A2: TclCompileScript (tclCompile.c:1455)
==24120== by 0x407AA9D: TclSetByteCodeFromAny (tclCompile.c:493)
==24120== by 0x407ACC6: SetByteCodeFromAny (tclCompile.c:588)
==24120== by 0x408F953: TclCompEvalObj (tclExecute.c:1017)
==24120== by 0x40459F1: TclEvalObjEx (tclBasic.c:4677)
[K01a] Same bug, different process:
==24120== 163 bytes in 5 blocks are definitely lost in loss record 3,120 of 4,124
==24120== at 0x401A846: malloc (vg_replace_malloc.c:149)
==24120== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==24120== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==24120== by 0x410FBBF: TclpGetNativeCwd (tclUnixFile.c:705)
==24120== by 0x40C59FA: Tcl_FSChdir (tclIOUtil.c:2980)
==24120== by 0x404CF17: Tcl_CdObjCmd (tclCmdAH.c:332)
==24120== by 0x4091D0C: TclExecuteByteCode (tclExecute.c:1834)
==24120== by 0x408F8EF: TclCompEvalObj (tclExecute.c:996)
==24120== by 0x40459F1: TclEvalObjEx (tclBasic.c:4677)
==24120== by 0x404CCD1: Tcl_CatchObjCmd (tclCmdAH.c:253)
[K16] In a subprocess of tcltest.test. I suspect that it's a leak
of a parameter and that dictionaries are the innocent victim.
==24120== 295 (20 direct, 275 indirect) bytes in 1 blocks are definitely lost in loss record 3,172 of 4,124
==24120== at 0x401A846: malloc (vg_replace_malloc.c:149)
==24120== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==24120== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==24120== by 0x40D9552: AllocObjEntry (tclObj.c:3287)
==24120== by 0x40ACF4E: Tcl_CreateHashEntry (tclHash.c:383)
==24120== by 0x4085003: Tcl_DictObjPut (tclDictObj.c:749)
==24120== by 0x4085932: DictCreateCmd (tclDictObj.c:1331)
==24120== by 0x4089305: Tcl_DictObjCmd (tclDictObj.c:2994)
==24120== by 0x40441E5: TclEvalObjvInternal (tclBasic.c:3617)
==24120== by 0x404516F: TclEvalEx (tclBasic.c:4221)
[K01e] [cd] yet again.
==24120== 385 bytes in 10 blocks are definitely lost in loss record 3,498 of 4,124
==24120== at 0x401A846: malloc (vg_replace_malloc.c:149)
==24120== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==24120== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==24120== by 0x410FBBF: TclpGetNativeCwd (tclUnixFile.c:705)
==24120== by 0x40C59FA: Tcl_FSChdir (tclIOUtil.c:2980)
==24120== by 0x404CF17: Tcl_CdObjCmd (tclCmdAH.c:332)
==24120== by 0x4091D0C: TclExecuteByteCode (tclExecute.c:1834)
==24120== by 0x408F6AB: Tcl_ExprObj (tclExecute.c:868)
==24120== by 0x4045FAD: Tcl_ExprBooleanObj (tclBasic.c:4968)
==24120== by 0x4050FB1: Tcl_IfObjCmd (tclCmdIL.c:207)
[K01f] [cd] yet again.
==24120== 1,440 bytes in 40 blocks are definitely lost in loss record 3,639 of 4,124
==24120== at 0x401A846: malloc (vg_replace_malloc.c:149)
==24120== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==24120== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==24120== by 0x410FBBF: TclpGetNativeCwd (tclUnixFile.c:705)
==24120== by 0x40C59FA: Tcl_FSChdir (tclIOUtil.c:2980)
==24120== by 0x404CF17: Tcl_CdObjCmd (tclCmdAH.c:332)
==24120== by 0x4091D0C: TclExecuteByteCode (tclExecute.c:1834)
==24120== by 0x408F8EF: TclCompEvalObj (tclExecute.c:996)
==24120== by 0x40459F1: TclEvalObjEx (tclBasic.c:4677)
==24120== by 0x40B13F4: SlaveEval (tclInterp.c:2491)
[K02] Same bug, different process
==24120== 3,671 (644 direct, 3,027 indirect) bytes in 23 blocks are definitely lost in loss record 3,681 of 4,124
==24120== at 0x401A846: malloc (vg_replace_malloc.c:149)
==24120== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==24120== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==24120== by 0x40DF7E9: SetFsPathFromAny (tclPathObj.c:2428)
==24120== by 0x40D6CF7: Tcl_ConvertToType (tclObj.c:584)
==24120== by 0x40DDE11: Tcl_FSConvertToPathType (tclPathObj.c:1161)
==24120== by 0x40DE695: Tcl_FSGetNormalizedPath (tclPathObj.c:1690)
==24120== by 0x40C472D: Tcl_FSEvalFileEx (tclIOUtil.c:1757)
==24120== by 0x405969D: Tcl_SourceObjCmd (tclCmdMZ.c:953)
==24120== by 0x40441E5: TclEvalObjvInternal (tclBasic.c:3617)
[K01f] Yet another way to get to [cd]
==24120== 1,154 bytes in 31 blocks are definitely lost in loss record 3,747 of 4,124
==24120== at 0x401A846: malloc (vg_replace_malloc.c:149)
==24120== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==24120== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==24120== by 0x410FBBF: TclpGetNativeCwd (tclUnixFile.c:705)
==24120== by 0x40C59FA: Tcl_FSChdir (tclIOUtil.c:2980)
==24120== by 0x404CF17: Tcl_CdObjCmd (tclCmdAH.c:332)
==24120== by 0x40441E5: TclEvalObjvInternal (tclBasic.c:3617)
==24120== by 0x404516F: TclEvalEx (tclBasic.c:4221)
==24120== by 0x404461B: Tcl_EvalEx (tclBasic.c:3892)
==24120== by 0x404585E: TclEvalObjEx (tclBasic.c:4592)
[K10] Another parameter leak, from tcltest.test. May or may not
be the same as the other [K10]s
==24120== 2,806 (432 direct, 2,374 indirect) bytes in 18 blocks are definitely lost in loss record 3,787 of 4,124
==24120== at 0x401A846: malloc (vg_replace_malloc.c:149)
==24120== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==24120== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==24120== by 0x40ED206: Tcl_NewStringObj (tclStringObj.c:210)
==24120== by 0x40DBF97: TclSubstTokens (tclParse.c:2176)
==24120== by 0x4044AB5: TclEvalEx (tclBasic.c:4086)
==24120== by 0x404461B: Tcl_EvalEx (tclBasic.c:3892)
==24120== by 0x40E1B29: Tcl_PkgRequireProc (tclPkg.c:493)
==24120== by 0x40E2E76: Tcl_PackageObjCmd (tclPkg.c:1013)
==24120== by 0x40441E5: TclEvalObjvInternal (tclBasic.c:3617)
[K12] In both tcltest.test and somewhere in [ghi.test]
==24120== 864 bytes in 36 blocks are definitely lost in loss record 3,889 of 4,124
==24120== at 0x401A846: malloc (vg_replace_malloc.c:149)
==24120== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==24120== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==24120== by 0x40D7C4B: Tcl_NewIntObj (tclObj.c:1833)
==24120== by 0x40BD8B7: FixLevelCode (tclIO.c:10008)
==24120== by 0x40BD6F3: Tcl_SetChannelError (tclIO.c:9933)
==24120== by 0x8054DF1: TestChannelCmd (tclTest.c:5635)
==24120== by 0x40424A8: TclInvokeStringCommand (tclBasic.c:2020)
==24120== by 0x40441E5: TclEvalObjvInternal (tclBasic.c:3617)
==24120== by 0x404516F: TclEvalEx (tclBasic.c:4221)
[K12a] In both tcltest.test and somewhere in [ghi]*.test. Likely the
same as [K12]
==24120== 864 bytes in 36 blocks are definitely lost in loss record 3,890 of 4,124
==24120== at 0x401A846: malloc (vg_replace_malloc.c:149)
==24120== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==24120== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==24120== by 0x40D7C4B: Tcl_NewIntObj (tclObj.c:1833)
==24120== by 0x40BD8B7: FixLevelCode (tclIO.c:10008)
==24120== by 0x40BD5FC: Tcl_SetChannelErrorInterp (tclIO.c:9897)
==24120== by 0x8054EAE: TestChannelCmd (tclTest.c:5648)
==24120== by 0x40424A8: TclInvokeStringCommand (tclBasic.c:2020)
==24120== by 0x40441E5: TclEvalObjvInternal (tclBasic.c:3617)
==24120== by 0x404516F: TclEvalEx (tclBasic.c:4221)
[K01] Yet another path into [cd]
==24120== 956 bytes in 26 blocks are definitely lost in loss record 3,900 of 4,124
==24120== at 0x401A846: malloc (vg_replace_malloc.c:149)
==24120== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==24120== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==24120== by 0x410FBBF: TclpGetNativeCwd (tclUnixFile.c:705)
==24120== by 0x40C59FA: Tcl_FSChdir (tclIOUtil.c:2980)
==24120== by 0x404CF17: Tcl_CdObjCmd (tclCmdAH.c:332)
==24120== by 0x4091D0C: TclExecuteByteCode (tclExecute.c:1834)
==24120== by 0x408F8EF: TclCompEvalObj (tclExecute.c:996)
==24120== by 0x40E758A: TclObjInterpProcCore (tclProc.c:1517)
==24120== by 0x40E6E25: ObjInterpProcEx (tclProc.c:1269)
[K25] Another leak in vfs
==23687== 72 (28 direct, 44 indirect) bytes in 1 blocks are definitely lost in loss record 1,713 of 3,976
==23687== at 0x401A846: malloc (vg_replace_malloc.c:149)
==23687== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==23687== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==23687== by 0x40DF7E9: SetFsPathFromAny (tclPathObj.c:2428)
==23687== by 0x40DF1D5: TclFSSetPathDetails (tclPathObj.c:2162)
==23687== by 0x40C6C9A: Tcl_FSGetFileSystemForPath (tclIOUtil.c:4432)
==23687== by 0x40C3C5D: Tcl_FSMatchInDirectory (tclIOUtil.c:1093)
==23687== by 0x80575FD: SimpleMatchInDirectory (tclTest.c:6809)
==23687== by 0x40C3CAE: Tcl_FSMatchInDirectory (tclIOUtil.c:1108)
==23687== by 0x40AC8EF: DoGlob (tclFileName.c:2456)
[K15a] known to happen in [mnopq]*.test:
==23687== 48 bytes in 2 blocks are definitely lost in loss record 1,931 of 3,976
==23687== at 0x401A846: malloc (vg_replace_malloc.c:149)
==23687== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==23687== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==23687== by 0x40E7169: TclObjInterpProcCore (tclProc.c:1439)
==23687== by 0x40E6E25: ObjInterpProcEx (tclProc.c:1269)
==23687== by 0x40E6CA1: TclObjInterpProc (tclProc.c:1199)
==23687== by 0x4091D0C: TclExecuteByteCode (tclExecute.c:1834)
==23687== by 0x408F8EF: TclCompEvalObj (tclExecute.c:996)
==23687== by 0x40459F1: TclEvalObjEx (tclBasic.c:4677)
==23687== by 0x404CCD1: Tcl_CatchObjCmd (tclCmdAH.c:253)
[K26] Another vfs leak
==23687== 55 bytes in 1 blocks are possibly lost in loss record 1,969 of 3,976
==23687== at 0x401A846: malloc (vg_replace_malloc.c:149)
==23687== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==23687== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==23687== by 0x41102C1: TclNativeCreateNativeRep (tclUnixFile.c:1102)
==23687== by 0x40DF0A1: Tcl_FSGetInternalRep (tclPathObj.c:2062)
==23687== by 0x40C6CE4: Tcl_FSGetNativePath (tclIOUtil.c:4475)
==23687== by 0x410FD4E: TclpObjStat (tclUnixFile.c:825)
==23687== by 0x40C4BD1: Tcl_FSStat (tclIOUtil.c:2021)
==23687== by 0x40C476C: Tcl_FSEvalFileEx (tclIOUtil.c:1765)
==23687== by 0x405969D: Tcl_SourceObjCmd (tclCmdMZ.c:953)
[K15] known to happen in [mnopq]*.test:
==23687== 72 bytes in 3 blocks are definitely lost in loss record 2,063 of 3,976
==23687== at 0x401A846: malloc (vg_replace_malloc.c:149)
==23687== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==23687== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==23687== by 0x40E7169: TclObjInterpProcCore (tclProc.c:1439)
==23687== by 0x40E6E25: ObjInterpProcEx (tclProc.c:1269)
==23687== by 0x40E6CA1: TclObjInterpProc (tclProc.c:1199)
==23687== by 0x40441E5: TclEvalObjvInternal (tclBasic.c:3617)
==23687== by 0x4044426: Tcl_EvalObjv (tclBasic.c:3737)
==23687== by 0x40D48A1: NsEnsembleImplementationCmd (tclNamesp.c:6243)
==23687== by 0x40441E5: TclEvalObjvInternal (tclBasic.c:3617)
[K18] unload.test - several of the tests appear to abandon the loaded
extension and its memory.
==23687== 78 (72 direct, 6 indirect) bytes in 3 blocks are definitely lost in loss record 2,121 of 3,976
==23687== at 0x401A846: malloc (vg_replace_malloc.c:149)
==23687== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==23687== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==23687== by 0x40ED206: Tcl_NewStringObj (tclStringObj.c:210)
==23687== by 0x40FF1E0: Tcl_SetVar2 (tclVar.c:1393)
==23687== by 0x40FF1B8: Tcl_SetVar (tclVar.c:1341)
==23687== by 0x4138BD4: ???
==23687== by 0x4138C99: ???
==23687== by 0x40CB60B: Tcl_LoadObjCmd (tclLoad.c:423)
==23687== by 0x40441E5: TclEvalObjvInternal (tclBasic.c:3617)
[K09] This is a literal leak, but it could be that the literal is
flowing into unload.test
==23687== 133 (120 direct, 13 indirect) bytes in 5 blocks are definitely lost in loss record 2,357 of 3,976
==23687== at 0x401A846: malloc (vg_replace_malloc.c:149)
==23687== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==23687== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==23687== by 0x40D6D28: Tcl_NewObj (tclObj.c:689)
==23687== by 0x407854A: ParseLexeme (tclCompExpr.c:2095)
==23687== by 0x4076192: ParseExpr (tclCompExpr.c:284)
==23687== by 0x4078827: TclCompileExpr (tclCompExpr.c:2319)
==23687== by 0x408F250: Tcl_ExprObj (tclExecute.c:788)
==23687== by 0x404D8C5: Tcl_ExprObjCmd (tclCmdAH.c:771)
==23687== by 0x40441E5: TclEvalObjvInternal (tclBasic.c:3617)
[K09a] Similar leak, different context
==23687== 133 (72 direct, 61 indirect) bytes in 3 blocks are definitely lost in loss record 2,369 of 3,976
==23687== at 0x401A846: malloc (vg_replace_malloc.c:149)
==23687== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==23687== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==23687== by 0x40D6D28: Tcl_NewObj (tclObj.c:689)
==23687== by 0x407854A: ParseLexeme (tclCompExpr.c:2095)
==23687== by 0x4076192: ParseExpr (tclCompExpr.c:284)
==23687== by 0x4078046: Tcl_ParseExpr (tclCompExpr.c:1139)
==23687== by 0x80520B2: TestexprparserObjCmd (tclTest.c:3388)
==23687== by 0x40441E5: TclEvalObjvInternal (tclBasic.c:3617)
==23687== by 0x404516F: TclEvalEx (tclBasic.c:4221)
[K18a] More abandoned memory in a loaded extension
==23687== 78 (72 direct, 6 indirect) bytes in 3 blocks are definitely lost in loss record 2,371 of 3,976
==23687== at 0x401A846: malloc (vg_replace_malloc.c:149)
==23687== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==23687== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==23687== by 0x40ED206: Tcl_NewStringObj (tclStringObj.c:210)
==23687== by 0x40FF1E0: Tcl_SetVar2 (tclVar.c:1393)
==23687== by 0x40FF1B8: Tcl_SetVar (tclVar.c:1341)
==23687== by 0x4138D5B: ???
==23687== by 0x4138DBF: ???
==23687== by 0x40CBE5D: Tcl_UnloadObjCmd (tclLoad.c:741)
==23687== by 0x40441E5: TclEvalObjvInternal (tclBasic.c:3617)
[K18b] More abandoned memory in a loaded extension
==23687== 104 (96 direct, 8 indirect) bytes in 4 blocks are definitely lost in loss record 2,386 of 3,976
==23687== at 0x401A846: malloc (vg_replace_malloc.c:149)
==23687== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==23687== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==23687== by 0x40ED206: Tcl_NewStringObj (tclStringObj.c:210)
==23687== by 0x40FF1E0: Tcl_SetVar2 (tclVar.c:1393)
==23687== by 0x40FF1B8: Tcl_SetVar (tclVar.c:1341)
==23687== by 0x4138BD4: ???
==23687== by 0x40CB657: Tcl_LoadObjCmd (tclLoad.c:432)
==23687== by 0x40441E5: TclEvalObjvInternal (tclBasic.c:3617)
==23687== by 0x404516F: TclEvalEx (tclBasic.c:4221)
[K10a] Need to isolate a test case.
==23687== 110 bytes in 2 blocks are possibly lost in loss record 2,387 of 3,976
==23687== at 0x401A846: malloc (vg_replace_malloc.c:149)
==23687== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==23687== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==23687== by 0x40ED260: Tcl_NewStringObj (tclStringObj.c:210)
==23687== by 0x40DBF97: TclSubstTokens (tclParse.c:2176)
==23687== by 0x4044AB5: TclEvalEx (tclBasic.c:4086)
==23687== by 0x404461B: Tcl_EvalEx (tclBasic.c:3892)
==23687== by 0x40E1B29: Tcl_PkgRequireProc (tclPkg.c:493)
==23687== by 0x40E2E76: Tcl_PackageObjCmd (tclPkg.c:1013)
==23687== by 0x40441E5: TclEvalObjvInternal (tclBasic.c:3617)
[K27] Need to isolate a test case
==23687== 136 (24 direct, 112 indirect) bytes in 1 blocks are definitely lost in loss record 2,401 of 3,976
==23687== at 0x401A846: malloc (vg_replace_malloc.c:149)
==23687== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==23687== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==23687== by 0x40ED206: Tcl_NewStringObj (tclStringObj.c:210)
==23687== by 0x40DBF97: TclSubstTokens (tclParse.c:2176)
==23687== by 0x4044AB5: TclEvalEx (tclBasic.c:4086)
==23687== by 0x404461B: Tcl_EvalEx (tclBasic.c:3892)
==23687== by 0x404585E: TclEvalObjEx (tclBasic.c:4592)
==23687== by 0x40455FE: Tcl_EvalObjEx (tclBasic.c:4475)
==23687== by 0x40E67A4: Tcl_UplevelObjCmd (tclProc.c:889)
==23687==
==23687==
==23687== 68 bytes in 2 blocks are definitely lost in loss record 2,410 of 3,976
[K01c] Same song, different verse
==23687== at 0x401A846: malloc (vg_replace_malloc.c:149)
==23687== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==23687== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==23687== by 0x410FBBF: TclpGetNativeCwd (tclUnixFile.c:705)
==23687== by 0x40C59FA: Tcl_FSChdir (tclIOUtil.c:2980)
==23687== by 0x40C6B53: Tcl_FSRemoveDirectory (tclIOUtil.c:4347)
==23687== by 0x40A7E1E: TclFileDeleteCmd (tclFCmd.c:392)
==23687== by 0x404DCAD: Tcl_FileObjCmd (tclCmdAH.c:918)
==23687== by 0x4091D0C: TclExecuteByteCode (tclExecute.c:1834)
==23687== by 0x408F8EF: TclCompEvalObj (tclExecute.c:996)
[K01f] again
==23687== 1,440 bytes in 40 blocks are definitely lost in loss record 2,605 of 3,976
==23687== at 0x401A846: malloc (vg_replace_malloc.c:149)
==23687== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==23687== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==23687== by 0x410FBBF: TclpGetNativeCwd (tclUnixFile.c:705)
==23687== by 0x40C59FA: Tcl_FSChdir (tclIOUtil.c:2980)
==23687== by 0x404CF17: Tcl_CdObjCmd (tclCmdAH.c:332)
==23687== by 0x4091D0C: TclExecuteByteCode (tclExecute.c:1834)
==23687== by 0x408F8EF: TclCompEvalObj (tclExecute.c:996)
==23687== by 0x40459F1: TclEvalObjEx (tclBasic.c:4677)
==23687== by 0x40B13F4: SlaveEval (tclInterp.c:2491)
[K02] again
==23687== 4,481 (784 direct, 3,697 indirect) bytes in 28 blocks are definitely lost in loss record 2,643 of 3,976
==23687== at 0x401A846: malloc (vg_replace_malloc.c:149)
==23687== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==23687== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==23687== by 0x40DF7E9: SetFsPathFromAny (tclPathObj.c:2428)
==23687== by 0x40D6CF7: Tcl_ConvertToType (tclObj.c:584)
==23687== by 0x40DDE11: Tcl_FSConvertToPathType (tclPathObj.c:1161)
==23687== by 0x40DE695: Tcl_FSGetNormalizedPath (tclPathObj.c:1690)
==23687== by 0x40C472D: Tcl_FSEvalFileEx (tclIOUtil.c:1757)
==23687== by 0x405969D: Tcl_SourceObjCmd (tclCmdMZ.c:953)
==23687== by 0x40441E5: TclEvalObjvInternal (tclBasic.c:3617)
[K02a] again
==23687== 996 (168 direct, 828 indirect) bytes in 6 blocks are definitely lost in loss record 2,645 of 3,976
==23687== at 0x401A846: malloc (vg_replace_malloc.c:149)
==23687== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==23687== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==23687== by 0x40DF7E9: SetFsPathFromAny (tclPathObj.c:2428)
==23687== by 0x40D6CF7: Tcl_ConvertToType (tclObj.c:584)
==23687== by 0x40DDE11: Tcl_FSConvertToPathType (tclPathObj.c:1161)
==23687== by 0x40DE695: Tcl_FSGetNormalizedPath (tclPathObj.c:1690)
==23687== by 0x40C472D: Tcl_FSEvalFileEx (tclIOUtil.c:1757)
==23687== by 0x405969D: Tcl_SourceObjCmd (tclCmdMZ.c:953)
==23687== by 0x4091D0C: TclExecuteByteCode (tclExecute.c:1834)
[K08b] Another leaky path through DoGlob
==23687== 372 (168 direct, 204 indirect) bytes in 6 blocks are definitely lost in loss record 2,675 of 3,976
==23687== at 0x401A846: malloc (vg_replace_malloc.c:149)
==23687== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==23687== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==23687== by 0x40DF7E9: SetFsPathFromAny (tclPathObj.c:2428)
==23687== by 0x40DF1D5: TclFSSetPathDetails (tclPathObj.c:2162)
==23687== by 0x40C6C9A: Tcl_FSGetFileSystemForPath (tclIOUtil.c:4432)
==23687== by 0x40C3C5D: Tcl_FSMatchInDirectory (tclIOUtil.c:1093)
==23687== by 0x80575FD: SimpleMatchInDirectory (tclTest.c:6809)
==23687== by 0x40C3CAE: Tcl_FSMatchInDirectory (tclIOUtil.c:1108)
==23687== by 0x40AC4E2: DoGlob (tclFileName.c:2334)
[K01] yet again
==23687== 1,154 bytes in 31 blocks are definitely lost in loss record 2,952 of 3,976
==23687== at 0x401A846: malloc (vg_replace_malloc.c:149)
==23687== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==23687== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==23687== by 0x410FBBF: TclpGetNativeCwd (tclUnixFile.c:705)
==23687== by 0x40C59FA: Tcl_FSChdir (tclIOUtil.c:2980)
==23687== by 0x404CF17: Tcl_CdObjCmd (tclCmdAH.c:332)
==23687== by 0x40441E5: TclEvalObjvInternal (tclBasic.c:3617)
==23687== by 0x404516F: TclEvalEx (tclBasic.c:4221)
==23687== by 0x404461B: Tcl_EvalEx (tclBasic.c:3892)
==23687== by 0x404585E: TclEvalObjEx (tclBasic.c:4592)
[K10a] Someone is leaking an obj, need to isolate the test case
==23687== 3,616 (552 direct, 3,064 indirect) bytes in 23 blocks are definitely lost in loss record 3,007 of 3,976
==23687== at 0x401A846: malloc (vg_replace_malloc.c:149)
==23687== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==23687== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==23687== by 0x40ED206: Tcl_NewStringObj (tclStringObj.c:210)
==23687== by 0x40DBF97: TclSubstTokens (tclParse.c:2176)
==23687== by 0x4044AB5: TclEvalEx (tclBasic.c:4086)
==23687== by 0x404461B: Tcl_EvalEx (tclBasic.c:3892)
==23687== by 0x40E1B29: Tcl_PkgRequireProc (tclPkg.c:493)
==23687== by 0x40E2E76: Tcl_PackageObjCmd (tclPkg.c:1013)
==23687== by 0x40441E5: TclEvalObjvInternal (tclBasic.c:3617)
[K12] fails in [ghi]*.test somewhere
==23687== 864 bytes in 36 blocks are definitely lost in loss record 3,030 of 3,976
==23687== at 0x401A846: malloc (vg_replace_malloc.c:149)
==23687== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==23687== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==23687== by 0x40D7C4B: Tcl_NewIntObj (tclObj.c:1833)
==23687== by 0x40BD8B7: FixLevelCode (tclIO.c:10008)
==23687== by 0x40BD5FC: Tcl_SetChannelErrorInterp (tclIO.c:9897)
==23687== by 0x8054EAE: TestChannelCmd (tclTest.c:5648)
==23687== by 0x40424A8: TclInvokeStringCommand (tclBasic.c:2020)
==23687== by 0x40441E5: TclEvalObjvInternal (tclBasic.c:3617)
==23687== by 0x404516F: TclEvalEx (tclBasic.c:4221)
[K11] fails in [ghi]*.test
==23687== 1,008 (144 direct, 864 indirect) bytes in 6 blocks are definitely lost in loss record 3,035 of 3,976
==23687== at 0x401A846: malloc (vg_replace_malloc.c:149)
==23687== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==23687== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==23687== by 0x40ED206: Tcl_NewStringObj (tclStringObj.c:210)
==23687== by 0x40DDA04: Tcl_FSJoinPath (tclPathObj.c:962)
==23687== by 0x40AA054: Tcl_FSJoinToPath (tclFileName.c:793)
==23687== by 0x404DFBD: Tcl_FileObjCmd (tclCmdAH.c:1005)
==23687== by 0x4091D0C: TclExecuteByteCode (tclExecute.c:1834)
==23687== by 0x408F8EF: TclCompEvalObj (tclExecute.c:996)
==23687== by 0x40E758A: TclObjInterpProcCore (tclProc.c:1517)
[K01] again in some variant
==23687== 160 bytes in 4 blocks are definitely lost in loss record 3,048 of 3,976
==23687== at 0x401A846: malloc (vg_replace_malloc.c:149)
==23687== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==23687== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==23687== by 0x410FBBF: TclpGetNativeCwd (tclUnixFile.c:705)
==23687== by 0x40C59FA: Tcl_FSChdir (tclIOUtil.c:2980)
==23687== by 0x404CF17: Tcl_CdObjCmd (tclCmdAH.c:332)
==23687== by 0x40441E5: TclEvalObjvInternal (tclBasic.c:3617)
==23687== by 0x404516F: TclEvalEx (tclBasic.c:4221)
==23687== by 0x404461B: Tcl_EvalEx (tclBasic.c:3892)
==23687== by 0x40C4993: Tcl_FSEvalFileEx (tclIOUtil.c:1818)
[K08a] in [def]*.test looks like a bug in the 'simple' filesystem
==23687== 296 (144 direct, 152 indirect) bytes in 6 blocks are definitely lost in loss record 3,098 of 3,976
==23687== at 0x401A846: malloc (vg_replace_malloc.c:149)
==23687== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==23687== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==23687== by 0x40ED206: Tcl_NewStringObj (tclStringObj.c:210)
==23687== by 0x8057578: SimpleRedirect (tclTest.c:6778)
==23687== by 0x80575DB: SimpleMatchInDirectory (tclTest.c:6807)
==23687== by 0x40C3CAE: Tcl_FSMatchInDirectory (tclIOUtil.c:1108)
==23687== by 0x40AC4E2: DoGlob (tclFileName.c:2334)
==23687== by 0x40ABB1F: TclGlob (tclFileName.c:1911)
==23687== by 0x40AB38A: Tcl_GlobObjCmd (tclFileName.c:1580)
Yet another variation on [K02]
==23687== 151 (24 direct, 127 indirect) bytes in 1 blocks are definitely lost in loss record 3,100 of 3,976
==23687== at 0x401A846: malloc (vg_replace_malloc.c:149)
==23687== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==23687== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==23687== by 0x40ED206: Tcl_NewStringObj (tclStringObj.c:210)
==23687== by 0x40DC630: TclFSNormalizeAbsolutePath (tclPathObj.c:235)
==23687== by 0x40DEE09: Tcl_FSGetNormalizedPath (tclPathObj.c:1920)
==23687== by 0x40C472D: Tcl_FSEvalFileEx (tclIOUtil.c:1757)
==23687== by 0x405969D: Tcl_SourceObjCmd (tclCmdMZ.c:953)
==23687== by 0x4091D0C: TclExecuteByteCode (tclExecute.c:1834)
==23687== by 0x408F8EF: TclCompEvalObj (tclExecute.c:996)
[K19] turns up inside all.tcl and tcltest; we don't know why. miguel
has a smallish test file that tickles the bug.
==23687== 146 (24 direct, 122 indirect) bytes in 1 blocks are definitely lost in loss record 3,193 of 3,976
==23687== at 0x401A846: malloc (vg_replace_malloc.c:149)
==23687== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==23687== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==23687== by 0x40C9646: SetListFromAny (tclListObj.c:1716)
==23687== by 0x40C874F: Tcl_ListObjLength (tclListObj.c:721)
==23687== by 0x40A1915: TclExecuteByteCode (tclExecute.c:5687)
==23687== by 0x408F8EF: TclCompEvalObj (tclExecute.c:996)
==23687== by 0x40E758A: TclObjInterpProcCore (tclProc.c:1517)
==23687== by 0x40E6E25: ObjInterpProcEx (tclProc.c:1269)
==23687== by 0x40E6CA1: TclObjInterpProc (tclProc.c:1199)
Yet another variant of [K01]
==23687== 152 bytes in 4 blocks are definitely lost in loss record 3,209 of 3,976
==23687== at 0x401A846: malloc (vg_replace_malloc.c:149)
==23687== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==23687== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==23687== by 0x410FBBF: TclpGetNativeCwd (tclUnixFile.c:705)
==23687== by 0x40C59FA: Tcl_FSChdir (tclIOUtil.c:2980)
==23687== by 0x404CF17: Tcl_CdObjCmd (tclCmdAH.c:332)
==23687== by 0x4091D0C: TclExecuteByteCode (tclExecute.c:1834)
==23687== by 0x408F8EF: TclCompEvalObj (tclExecute.c:996)
==23687== by 0x40459F1: TclEvalObjEx (tclBasic.c:4677)
==23687== by 0x40D0EC5: NamespaceEvalCmd (tclNamesp.c:3472)
Yet another variant of [K10]
==23687== 162 (24 direct, 138 indirect) bytes in 1 blocks are definitely lost in loss record 3,210 of 3,976
==23687== at 0x401A846: malloc (vg_replace_malloc.c:149)
==23687== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==23687== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==23687== by 0x40ED206: Tcl_NewStringObj (tclStringObj.c:210)
==23687== by 0x40DBF97: TclSubstTokens (tclParse.c:2176)
==23687== by 0x4044AB5: TclEvalEx (tclBasic.c:4086)
==23687== by 0x404461B: Tcl_EvalEx (tclBasic.c:3892)
==23687== by 0x40E1B29: Tcl_PkgRequireProc (tclPkg.c:493)
==23687== by 0x40E2E76: Tcl_PackageObjCmd (tclPkg.c:1013)
==23687== by 0x4091D0C: TclExecuteByteCode (tclExecute.c:1834)
Some more variants of [K18]
==23687== 78 (72 direct, 6 indirect) bytes in 3 blocks are definitely lost in loss record 3,319 of 3,976
==23687== at 0x401A846: malloc (vg_replace_malloc.c:149)
==23687== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==23687== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==23687== by 0x40ED206: Tcl_NewStringObj (tclStringObj.c:210)
==23687== by 0x40FF1E0: Tcl_SetVar2 (tclVar.c:1393)
==23687== by 0x40FF1B8: Tcl_SetVar (tclVar.c:1341)
==23687== by 0x4138D8C: ???
==23687== by 0x40CBE5D: Tcl_UnloadObjCmd (tclLoad.c:741)
==23687== by 0x40441E5: TclEvalObjvInternal (tclBasic.c:3617)
==23687== by 0x404516F: TclEvalEx (tclBasic.c:4221)
[K18]
==23687== 104 (96 direct, 8 indirect) bytes in 4 blocks are definitely lost in loss record 3,329 of 3,976
==23687== at 0x401A846: malloc (vg_replace_malloc.c:149)
==23687== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==23687== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==23687== by 0x40ED206: Tcl_NewStringObj (tclStringObj.c:210)
==23687== by 0x40FF1E0: Tcl_SetVar2 (tclVar.c:1393)
==23687== by 0x40FF1B8: Tcl_SetVar (tclVar.c:1341)
==23687== by 0x4138D5B: ???
==23687== by 0x40CBE5D: Tcl_UnloadObjCmd (tclLoad.c:741)
==23687== by 0x40441E5: TclEvalObjvInternal (tclBasic.c:3617)
==23687== by 0x404516F: TclEvalEx (tclBasic.c:4221)
Another context for [K10] These may all be separate bugs because
they're likely commands leaking their parameters
==23687== 136 (24 direct, 112 indirect) bytes in 1 blocks are definitely lost in loss record 3,338 of 3,976
==23687== at 0x401A846: malloc (vg_replace_malloc.c:149)
==23687== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==23687== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==23687== by 0x40C9E04: TclRegisterLiteral (tclLiteral.c:348)
==23687== by 0x407DED9: TclCompileTokens (tclCompile.c:1840)
==23687== by 0x407C3A2: TclCompileScript (tclCompile.c:1455)
==23687== by 0x407AA9D: TclSetByteCodeFromAny (tclCompile.c:493)
==23687== by 0x407ACC6: SetByteCodeFromAny (tclCompile.c:588)
==23687== by 0x408F953: TclCompEvalObj (tclExecute.c:1017)
==23687== by 0x40459F1: TclEvalObjEx (tclBasic.c:4677)
[K18] again
==23687== 52 (48 direct, 4 indirect) bytes in 2 blocks are definitely lost in loss record 3,366 of 3,976
==23687== at 0x401A846: malloc (vg_replace_malloc.c:149)
==23687== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==23687== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==23687== by 0x40ED206: Tcl_NewStringObj (tclStringObj.c:210)
==23687== by 0x40FF1E0: Tcl_SetVar2 (tclVar.c:1393)
==23687== by 0x40FF1B8: Tcl_SetVar (tclVar.c:1341)
==23687== by 0x4138D8C: ???
==23687== by 0x4138DBF: ???
==23687== by 0x40CBE5D: Tcl_UnloadObjCmd (tclLoad.c:741)
==23687== by 0x40441E5: TclEvalObjvInternal (tclBasic.c:3617)
[K01] again
==23687== 163 bytes in 5 blocks are definitely lost in loss record 3,398 of 3,976
==23687== at 0x401A846: malloc (vg_replace_malloc.c:149)
==23687== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==23687== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==23687== by 0x410FBBF: TclpGetNativeCwd (tclUnixFile.c:705)
==23687== by 0x40C59FA: Tcl_FSChdir (tclIOUtil.c:2980)
==23687== by 0x404CF17: Tcl_CdObjCmd (tclCmdAH.c:332)
==23687== by 0x4091D0C: TclExecuteByteCode (tclExecute.c:1834)
==23687== by 0x408F8EF: TclCompEvalObj (tclExecute.c:996)
==23687== by 0x40459F1: TclEvalObjEx (tclBasic.c:4677)
==23687== by 0x404CCD1: Tcl_CatchObjCmd (tclCmdAH.c:253)
[K16] again. This one may be a leaked parameter. [rst]*.test
==23687== 295 (20 direct, 275 indirect) bytes in 1 blocks are definitely lost in loss record 3,445 of 3,976
==23687== at 0x401A846: malloc (vg_replace_malloc.c:149)
==23687== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==23687== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==23687== by 0x40D9552: AllocObjEntry (tclObj.c:3287)
==23687== by 0x40ACF4E: Tcl_CreateHashEntry (tclHash.c:383)
==23687== by 0x4085003: Tcl_DictObjPut (tclDictObj.c:749)
==23687== by 0x4085932: DictCreateCmd (tclDictObj.c:1331)
==23687== by 0x4089305: Tcl_DictObjCmd (tclDictObj.c:2994)
==23687== by 0x40441E5: TclEvalObjvInternal (tclBasic.c:3617)
==23687== by 0x404516F: TclEvalEx (tclBasic.c:4221)
[K01] cd again
==23687== 385 bytes in 10 blocks are definitely lost in loss record 3,720 of 3,976
==23687== at 0x401A846: malloc (vg_replace_malloc.c:149)
==23687== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==23687== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==23687== by 0x410FBBF: TclpGetNativeCwd (tclUnixFile.c:705)
==23687== by 0x40C59FA: Tcl_FSChdir (tclIOUtil.c:2980)
==23687== by 0x404CF17: Tcl_CdObjCmd (tclCmdAH.c:332)
==23687== by 0x4091D0C: TclExecuteByteCode (tclExecute.c:1834)
==23687== by 0x408F6AB: Tcl_ExprObj (tclExecute.c:868)
==23687== by 0x4045FAD: Tcl_ExprBooleanObj (tclBasic.c:4968)
==23687== by 0x4050FB1: Tcl_IfObjCmd (tclCmdIL.c:207)
[K12] again
==23687== 864 bytes in 36 blocks are definitely lost in loss record 3,796 of 3,976
==23687== at 0x401A846: malloc (vg_replace_malloc.c:149)
==23687== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==23687== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==23687== by 0x40D7C4B: Tcl_NewIntObj (tclObj.c:1833)
==23687== by 0x40BD8B7: FixLevelCode (tclIO.c:10008)
==23687== by 0x40BD6F3: Tcl_SetChannelError (tclIO.c:9933)
==23687== by 0x8054DF1: TestChannelCmd (tclTest.c:5635)
==23687== by 0x40424A8: TclInvokeStringCommand (tclBasic.c:2020)
==23687== by 0x40441E5: TclEvalObjvInternal (tclBasic.c:3617)
==23687== by 0x404516F: TclEvalEx (tclBasic.c:4221)
[K01] yet another context
==23687== 2,166 bytes in 54 blocks are definitely lost in loss record 3,851 of 3,976
==23687== at 0x401A846: malloc (vg_replace_malloc.c:149)
==23687== by 0x404001D: TclpAlloc (tclAlloc.c:710)
==23687== by 0x404A5C1: Tcl_Alloc (tclCkalloc.c:1019)
==23687== by 0x410FBBF: TclpGetNativeCwd (tclUnixFile.c:705)
==23687== by 0x40C59FA: Tcl_FSChdir (tclIOUtil.c:2980)
==23687== by 0x404CF17: Tcl_CdObjCmd (tclCmdAH.c:332)
==23687== by 0x4091D0C: TclExecuteByteCode (tclExecute.c:1834)
==23687== by 0x408F8EF: TclCompEvalObj (tclExecute.c:996)
==23687== by 0x40E758A: TclObjInterpProcCore (tclProc.c:1517)
==23687== by 0x40E6E25: ObjInterpProcEx (tclProc.c:1269)
