Joel Rosdahl [Sat, 27 Aug 2022 18:04:26 +0000 (20:04 +0200)]
test: Disable "output file failure" test for unsupported filesystem
The "Failure to write output file" test assumes that the filesystem
supports read-only directories. Improve this by probing this assumption
before running the test.
Joel Rosdahl [Mon, 1 Aug 2022 12:53:52 +0000 (14:53 +0200)]
fix: Always rewrite dependency file if base_dir is used
[1] added the has_absolute_include_headers variable as a performance
optimization for base_dir/CCACHE_BASEDIR so that the dependency file
only has to be parsed/rewritten when necessary. This is based on the
assumption that if no include file has an absolute path then no rewrite
is needed, but apparently Clang can insert other paths into the
dependency file as well, for instance the asan_blacklist.txt file when
using -fsanitize=address.
Fix this by simply always parsing the dependency file when base_dir is
active.
Joel Rosdahl [Sun, 17 Jul 2022 19:55:06 +0000 (21:55 +0200)]
fix: Avoid false success for -fcolor-diagnostics probe with GCC
Ccache will produce a false hit in the following scenario, if "cc" is
GCC without being a symlink to "gcc":
1. ccache cc -c example.c # adds a cache entry
2. ccache cc -c example.c -fcolor-diagnostics # unexpectedly succeeds
(Most major Linux distributions install cc as a symlink to gcc, and then
the problem doesn't show up since ccache then is able to guess that the
compiler is GCC.)
This bug was introduced by [1] which tried to make yet another tweak of
the color diagnostics guessing/probing by no longer rejecting
-fcolor-diagnostics for an unknown compiler, based on the assumption
that the probing call (speculatively adding -fdiagnostics-color) is only
made when we have guessed a GCC compiler. Unfortunately, this broke the
fix in [2] when the compiler is unknown.
All of this is inherently brittle and I don't see any good way to make
it better with the current compiler guessing approach and adding options
speculatively. The cure is to start doing proper compiler identification
instead (#958). Until that is done, the only reasonable fix is to avoid
doing anything related to color diagnostics flags when the compiler is
unknown. This means that an unknown compiler from now on won't produce
colors when used via ccache even if the compiler actually is GCC or
Clang.
Joel Rosdahl [Sat, 18 Jun 2022 18:08:10 +0000 (20:08 +0200)]
fix: Use a cleanup stamp instead of directory timestamp for cleanup
In order to know when to clean up the temporary directory, ccache checks
mtime of $CCACHE_DIR and updates it to "now" on cleanup. This doesn't
work well when the configuration file is modified often since that also
updates the same mtime.
Fix this by using a separate cleanup stamp file instead.
Joel Rosdahl [Sat, 18 Jun 2022 17:55:02 +0000 (19:55 +0200)]
fix: Clean up temporary dir if it's left the default
Cleanup of the temporary directory is done if it is $CCACHE_DIR/tmp,
which used to be the default until [1] where the default was changed to
/run/user/$UID/ccache-tmp. Improve this so that cleanup happens if the
temporary directory is equal to the default regardless of the default.
Joel Rosdahl [Tue, 7 Jun 2022 14:53:44 +0000 (16:53 +0200)]
fix: Use correct umask when populating primary cache from secondary
Util::get_umask retrieves the process's umask and caches it to avoid
some system calls. This doesn't interact well now when using UmaskScope
to change umask temporarily since Util::get_umask then only sometimes
returns the correct value. This leads to the incorrect umask being used
when writing cache entries to the primary storage for secondary storage
hits.
Joel Rosdahl [Tue, 7 Jun 2022 13:12:03 +0000 (15:12 +0200)]
fix: Create temporary file with cpp extension instead of hard linking
[1] added a suitable file extension to the temporary file used for
capturing the preprocessed output by creating a hard link. This fails
when the temporary directory is on a file system that doesn't support
hard links.
Fix this by making it possible to pass a suffix to TemporaryFile and
passing the proper cpp suffix for the tmp stdout file instead of
creating a hard link as an alias.
jacobly0 [Sun, 1 May 2022 16:10:56 +0000 (18:10 +0200)]
fix: Fix sporadic test.profiling failures (#1056)
Using cut, which is always line-based, to remove bytes from a binary file can
cause problems if the binary timestamp field happens to contain a newline
character, which causes test.profiling to fail <1% of the time. Instead use tail
which has a character mode that ignores newlines.
Joel Rosdahl [Sun, 1 May 2022 11:15:37 +0000 (13:15 +0200)]
fix: Isolate inode cache file in tests
All test suites use the default temporary directory location
/run/user/<UID>/ccache-tmp when possible, which means that the inode
cache file is shared between all test suites. This is problematic when
running test suites in parallel since one test suite may run “ccache -C”
(which removes the inode cache file) between two compilations in the
inode_cache suite, thus making the second compilation not behave as
expected, failing the test.
Fix this by putting the temporary directory inside the test-specific
ccache directory instead of using the default global location.
The Util::normalize_absolute_path function only works on the syntactic
level, i.e. the result may not actually resolve to the same filesystem
entry (nor to any file system entry for that matter). It was meant to be
used for paths that don’t necessarily exist yet, such as a future
directory in which to write debug files. It may fail in edge cases with
symlinks in the path in combination with .. segments. If the caller
wants to ensure that the resulting path actually makes sense, it needs
to check if the resulting path points to the same file entry as the
original.
To improve on this, Util::normalize_absolute_path has now been renamed
to Util::normalize_abstract_absolute_path and there is a new
Util::normalize_concrete_absolute_path function which returns the
original path if the normalized result doesn't resolve to the same file
system entry as the original path.
Joel Rosdahl [Wed, 6 Apr 2022 19:37:04 +0000 (21:37 +0200)]
fix: Fix process_preprocessed_file bug for distcc marker
2044fea84b86001b2976ecde946d3d6d0e88ec0a (included in ccache 4.6)
removed the special-casing of distcc’s pump in
process_preprocessed_file. That in turn revealed a bug that has been
present since 432d1ca6a6aa51f708124172169073c399fb68d2 (included in
ccache 3.4) but previously only affected compilations with distcc-pump
as the “compiler”: the detection and handling of distcc-pump’s
“__________” messages is broken in two ways:
1. It throws away everything between the last preprocessor directive and
the “__________” marker. Thus, changes to such sections will not be
included in the hash.
2. It detects “__________” markers in the middle of lines, not only at
the beginning of lines.
Orgad Shaneh [Fri, 25 Mar 2022 14:27:39 +0000 (17:27 +0300)]
fix: Do not add redundant newlines for stdout
Tokenizer is used with include_empty, and the output typically ends with
\n.
For each line, tokenizer returns it without the \n, and the function
appends
it. But if the output ends with \n, the tokenizer returns an additional
empty string, and a redundant LF is written to stdout.
Another issue can be if the last line of the original output doesn't end
with \n at all, ccache added it anyway.
It was probably unnoticed until now since gcc has no output at all, while
cl outputs the source file name.
Joel Rosdahl [Sun, 3 Apr 2022 08:50:43 +0000 (10:50 +0200)]
fix: Only use /run/user/<UID>/ccache-tmp if writable
The fix for #984 addressed a problem when /run/user/0 already exists and
ccache is run with fakeroot. However, it didn’t handle the case when
/run/user/0/ccache-tmp already exists, which will happen for instance if
the real root user has run ccache at least once.
Fix this by using access(2) to verify that the ccache-tmp directory is
writable. Note: Can’t just check the mode bits of the directory since
they appear OK since fakeroot fakes the UID.
Joel Rosdahl [Sun, 3 Apr 2022 06:59:46 +0000 (08:59 +0200)]
fix: Improve handling of .gcno files
When support for caching a compilation with coverage (producing a .gcno
file), the commit[1] made sure to avoid rewriting the input path to
relative with the motivation “also make sure to use the source file
path, since this is in the notes”. However, this seems to be unnecessary
since a relative input file path will be written as is to the .gcno, not
the absolute path. This is the case for at least GCC 4.7+ and Clang
3.6+. Fix this by potentially converting the input path to relative even
when generating coverage.
When investigating the above issue, I noticed that GCC 9+ includes the
current working directory (CWD) in the .gcno file. This means that we
have include the CWD in the hash when compiling with
-ftest-coverage/--coverage in order to replicate what the compiler would
produce. Since this makes it impossible get cache hits when compiling in
different directories, a new gcno_cwd sloppiness has been added for
opting out of hashing the CWD, with the tradeoff of potentially getting
an incorrect directory in the .gcno file.