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)