Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: 37. File System
Group: obsolete: 8.5.8
Submitted By: Neil Hampton (neilhampton)
Assigned to: Don Porter (dgp)
Summary: Crash in Tcl_FSGetFileSystemForPath
We have a multi-threaded tclkit application that runs several scripts on different threads and it crashes in Tcl_FSGetFileSystemForPath on the line "fsRecPtr = fsRecPtr->nextPtr".
>From investigation, it appears that 'theFilesystemEpoch' is being updated within the loop and the threads file system list is being re-cached leaving fsRecPtr pointing at freed memory. It is very difficult to track, but it appears that Tcl_FSMountsChanged is being called from within Tcl_FSGetFileSystemForPath. The path being accessed is the 'wrapped' init.tcl.
Comment By: Don Porter (dgp)
Date: 2012-06-11 09:41
The issue appears to be care needed by callers of
FsGetFirstFilesystem(). Any caller that keeps and
makes use of the value it returns needs to take care
not to continue using that value whenever another
call to FsGetFirstFilesystem() might be made in the
same thread. Since TclFSEnsureEpochOk() does
just that, it's clear that Tcl_FsGetFileSystemForPath()
has the potential for this kind of trouble. The need to
make both those calls and make sure they both report
results on the same epoch is a bit of a puzzle.