Tcl Source Code

SetFsPathFromAny duplicates a Tcl_Obj and then stores a pointer to the new object in a fsPathPtr, which it then sets as the internal representation of another Tcl_Obj, pathPtr. Because no care is taken to ensure that the internal representation of the newly-duplicated Tcl_Obj contains no reference-counted copy of pathPtr, it's possible for a situation to arise where pathPtr contains a pointer to itself, and that its reference count therefore never drops to 0, which is a memory leak.

In test Tcl_Main-2.1 such a situation does in fact occur: "result" is a literal value that, by the time SetFsPathFromAny receives it, has already been entered into the literalTable of the interpreter, and has also received an internal representation of type "localVarNameType", possibly due to its appearance in procedures within msgcat.tcl. When pathPtr is duplicated, DupLocalVarName() makes pathPtr the internal representation of the duplicated object, transPtr. Then transPtr is stored in fsPathPtr, which becomtes the internal representation of pathPtr. Valgrind reports still-reachable blocks due to this situation, but only when all other tests are deleted from the source file.

Although this issue can be fixed by modifying SetFsPathFromAny, it is yet another example of how sharing a single Tcl_Obj between identical literal values causes trouble. First, it creates a situation where there is only one internal representation even though the identical literal values may have different contexts and interpretations. Second, it makes errors like this one, which can go undiscovered for years, more likely.

Correction: Fixed in [a9c542391a86a9e8].

Fixed in [1ec9da4c469c29f4].