| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
in many places where possible.
|
| |
|
|
|
|
| |
NULL. This should fix [5da26d4760]: Tcl_LoadFile() segfaults if "interp" is NULL.
|
|
|
|
| |
And prevent them ever becoming 0 due to an overflow. (backported with variation from androwish)
|
|
|
|
| |
path objects. Needed for AndroWish/TclKit (???) in obscure situations, harmless on systems which only have a single native filesystem.
|
|\
| |
| |
| |
| | |
platforms into the trunk. For details see the merged revision and its
ancestor.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
regarding the handling of wrapped dynamic libraries.
The basic flow of operation is to copy such libraries into a temp
file, hand them to the OS loader for processing, and then to delete
them immediately, to prevent them from being accessible to other
executables. On platforms where that is not possible the library is
left in place and things are arranged to delete it on regular process
exit.
An example of the latter are older revisions of HPUX which report that
the file is busy when trying to delete it. Younger revisions of HPUX
have changed to allow the deletion, but are also buggy, the OS loader
mangles its data structures so that a second library loaded in this
manner fails.
More recently it was found that Linux which is usually ok with
deleting the file and gets everything right shows the same trouble as
modern HPUX when the "docker" containerization system is involved, or
more specifically the AUFS in use there. Deleting the loaded library
file mangles data structures and breaks loading of the following
libraries. For a demonstration which does not involve Tcl at all see
the ticket
https://github.com/dotcloud/docker/issues/1911
in the docker tracker.
This of course breaks the use of wrapped executables within docker
containers.
This commit introduces the function TclSkipUnlink() which centralizes
the handling of such exceptions to unlinking the library after unload,
and provides code handling the known cases. IOW HPUX is generally
forced to not unlink, and ditto when we detect that the copied library
file resides within an AUFS.
The latter must however be explicitly activated by setting the define
-DTCL_TEMPLOAD_NO_UNLINK during build. We still need proper configure
tests to set it on the relevant platforms (i.e. Linux).
The AUFS detection and handling can be overridden by the environment
variable TCL_TEMPLOAD_NO_UNLINK which can force the behaviour either
way (skip or not). In case the user knows best, or wishes to test if
the problem with AUFS has been fixed.
|
| |
| |
| |
| |
| | |
Clang/LLVM) don't define it, and _WIN32 is much more portable anyway.
See: [http://nadeausoftware.com/articles/2012/01/c_c_tip_how_use_compiler_predefined_macros_detect_operating_system#WindowsCygwinnonPOSIXandMinGW]
|
| | |
|
| | |
|
| | |
|
|\ \
| |/ |
|
| | |
|
|\ \
| |/
| |
| | |
Tcl_StatBuf has an "#include <sys/stat.h>" before including tcl.h
|
| |
| |
| |
| | |
Tcl_StatBuf has an "#include <sys/stat.h>" before including tcl.h
|
| |\
| | |
| | |
| | | |
for upwards compatibility with version 2 filesystems
|
| | |
| | |
| | |
| | | |
for upwards compatibility with version 2 filesystems
|
| | | |
|
| | | |
|
|\ \ \
| |/ /
| | |
| | | |
these flags are available through the whole filesystem for (future) internal use
|
| | | |
|
| | |
| | |
| | |
| | | |
clarification of #endifs, reduction of unnecessary casts, use of array syntax
for reading array elements, etc.)
|
| | | | |
| \ \ | |
|\ \ \ \
| | |/ /
| | | | |
for the filesystem subsystem.
|
| |/ /
| | |
| | | |
for the filesystem subsystem.
|
| | | |
|
| | | |
|
| | | |
|
|\ \ \
| |/ / |
|
| | | |
|
|\ \ \
| |/ /
| | |
| | |
| | | |
currently registered is only updated at times when no active loops are
traversing it. Also reduce the amount of epoch storing and checking to
where it can make a difference.
|
| | | |
|
| |\ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
prevent any overwriting of that per-thread cache. This keeps active traversals
of the list valid. The possible downside is that this may result in some delay
in noticing new epochs and result in somewhat greater likelihood we will cache
things in a "path" value that are out of date. Since the system has to deal
with out of date cached data anyway, this should have no correctness affects,
measured against the status quo. In multi-threaded operation the possibility
of caching and/or retrieving outdated information can never be eliminated.
Checkin also includes merge of 8.5.
|
| |\ \ \
| | |/ / |
|
| |\ \ \ |
|
| |\ \ \ \ |
|
| | | | | |
| | | | | |
| | | | | | |
something we are caching.
|
| |\ \ \ \ \ |
|
| | | | | | |
| | | | | | |
| | | | | | | |
by the test attached to Tcl Bug 3024359.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
The problem with release of the elements of a fileSystemList by one routine
while some other (caller) routine is still traversing that list is not
dependent on threaded operations. An unthreaded build can still encounter
the problem. Revised so that threaded/unthreaded operations are much closer
to the same (no direct TCL_THREADS dependency). Also simplified the epoch
checking which reduces locking to when it's needed. Still have the problem
of returning as valid FilesystemRecords that are pulled from an outdated
epoch.
|
| | | | | | | |
|
| | | | | | | |
|
|\ \ \ \ \ \ \
| | |_|_|_|/ /
| |/| | | | | |
|
| | |_|_|/ /
| |/| | | | |
|
|\ \ \ \ \ \
| |/ / / / /
| | | | | |
| | | | | |
| | | | | | |
memory
are more likely to segfault and not remain hidden.
|
| | |_|/ /
| |/| | |
| | | | | |
memory are more likely to segfault and not remain hidden.
|
|\ \ \ \ \
| |/ / / /
| | | | | |
Store the Tcl_Filesystem instead, which is what we actually need.
|
| | |/ /
| |/| |
| | | | |
Store the Tcl_Filesystem instead, which is what we actually need.
|
| | | | | |
| \ \ \ | |
|\ \ \ \ \
| | |/ / / |
|
| | |\ \ \
| |/ / / /
| | | | _ |
|