Bug 8728 - ccache gets confused by old dates and files in both $PWD and -I paths
Summary: ccache gets confused by old dates and files in both $PWD and -I paths
Status: RESOLVED DUPLICATE of bug 8424
Alias: None
Product: ccache
Classification: Unclassified
Component: ccache (show other bugs)
Version: 3.1.7
Hardware: All All
: P5 normal
Target Milestone: ---
Assignee: Joel Rosdahl
QA Contact: Joel Rosdahl
Depends on:
Reported: 2012-01-30 06:12 UTC by Mike Frysinger
Modified: 2013-10-20 09:18 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Mike Frysinger 2012-01-30 06:12:08 UTC
with some simple code, seems that ccache ends up searching -I paths *before* $PWD when looking for files included as "file.h".  seems the datestamps cause misbehavior in some way ?

simple test code below.  to reproduce, i checked out latest ccache code (5cdd7980895683613026967ac190c4a5bea196f3), then made a subdir in there called "foo" and added the code below to a shell script called "doit.sh".  upon running `./doit.sh`, it caught the misbehavior -- the 2nd compile picked up y.h from the subdir "dir/" instead of the one in $PWD, so "STR" was defined to "B" instead of "C".

if i remove the "touch" from the script, then things work as expected ...

tested ccache-2.4 works, but ccache-3.0 and ccache-3.1.7 fail.  a git bisect shows commit 702db98740f0a76998a03f6d7c043e7d5f94c8ae as the first bad one.

rm -rf .ccache
export CCACHE_DIR=$PWD/.ccache


rm -rf t && mkdir t && cd t

cat <<\EOF > y.c
#include "y.h"

mkdir dir
echo '#define STR "B"' > dir/y.h
touch -d '2008-12-03 15:37' dir/y.h

$c gcc -Idir -c y.c -o y.o
$c gcc y.o -o y
[[ $(./y) == "B" ]]

echo '#define STR "C"' > y.h
$c gcc -Idir -c y.c -o y.o
$c gcc y.o -o y
if [[ $(./y) != "C" ]] ; then
    echo "FAIL"
    exit 1
    echo "PASS"
    exit 0
Comment 1 Joel Rosdahl 2012-02-01 07:19:13 UTC
This has the same root cause as bug 8424: a design bug in the direct mode. It's not directly related to timestamps but rather to the way the direct mode works. The problem is that in the direct mode, ccache records header files that was used by the compiler, but it doesn't record header files that were not used but could have been used if they existed. So, when ccache checks if a result could be taken from the cache, it currently can't check if the existence of a new header file should invalidate the result.

I can think of some ways of making the problem less likely, but I haven't found any good solution.
Comment 2 Joel Rosdahl 2013-10-20 09:18:37 UTC

*** This bug has been marked as a duplicate of bug 8424 ***