The most recent commit to tclPathObj.c,
1.62 -> 1.63, causes a crash in the
trofs test suite (test trofs-12.8).
Logged In: YES
Looking like this is really a bug
in trofs, just exposed by the changes
to refcount logic. These changes
appear to have extended (created?)
a Hairy Monster nature for the
The pathPtr passed in to
zero refCount. Since the pointer is
stored, there ought to be a refcount
to go with that. Still need to look
it over with care, but that's probably
Nope. trofs never touches that
field at all. It's the Tcl core
that permits that field to hold
a pointer value, but leave the
Tcl_Obj pointed to with zero refcount,
apparently due to some very complex
requirements of some circular reference
Was able to workaround the issue
with changes to trofs. The code which
is not safe looks like:
Tcl_FSJoinToPath(parent, 1, &element));
where T_FSJTP can return a zero
refcount Tcl_Obj, and T_FSGNP can
free it just by trying to determine
its normalized form.
Probably should add warnings to the
docs that it's not safe to pass
zero refcount pathPtr values to
Something else to consider is whether
T_FSGNP ought to immediately panic
if handed a zero refcount pathPtr.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.