Suggests that at least one contibutor
to the error is that Tcl's internal
record of what is the current working
directory is not initialized at a time
when other parts of Tcl's filesystem
code may be assuming that it is initialized.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

From the comments about 'struct FsPath'
on lines 57-64 of tclPathObj.c:

* (i) flags == 0, => Ordinary path.
*
* translatedPathPtr contains the translated path (which may be a circular
* reference to the object itself). If it is NULL then the path is pure
* normalized (and the normPathPtr will be a circular reference). cwdPtr is
* null for an absolute path, and non-null for a relative path (unless the cwd
* has never been set, in which case the cwdPtr may also be null for a
* relative path).

Take care to note that cwdPtr==NULL is possible for a
relative path when the global cwd has never been set.
The code at lines 1773-1174 (in Tcl_FSGetNormalizedPath())
fails to account for this possibility.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Lines 1773-1774 are more reasonable than
I thought. When they run, we have already
called Tcl_FSGetNormalizedPath() on
fsPathPtr->cwdPtr, so for any normal value,
that call should have established
cwdPtr!=NULL. That's only false because
the empty string value as a pathname is
so weird (see 2001389).

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

pointsman reports that commenting
out line 1910 of Revision 1.66.2.3
of tclPathObj.c plugs the leak.

This indicates that somehow refCounting
is broken, but I'm not yet able to
sort it out. I think it has something
to do with not accounting for the strange
Tcl_FSGetCwd() interface that increments
refcount for the caller.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link: