Tcl Source Code

[https://core.tcl-lang.org/tcl/file?udc=1&ln=2359&ci=c02747a663bc158a&name=generic%2FtclPathObj.c|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()
[https://core.tcl-lang.org/tcl/file?udc=1&ln=5809&ci=c02747a663bc158a&name=generic%2FtclVar.c|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].