ccache 3.2.2. I do a plain "./configure" for configuration and "make" completes flawlessly.
Nevertheless any "should be hit" in the cache results in a "core dump".
Doing a "make test" I get this
jcea@ubuntu:~/video/zz/zz/ccache-3.2.2$ make test
PASSED: 448 assertions, 88 tests, 10 suites
version: gcc (Ubuntu 4.8.1-2ubuntu1~10.04.1) 4.8.1 Copyright (C) 2013 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
test dir: testdir.16744
starting testsuite base
starting testsuite link
starting testsuite hardlink
starting testsuite nlevels4
starting testsuite nlevels1
starting testsuite basedir
SUITE: "basedir", TEST: "set CCACHE_BASEDIR, direct lookup" - Expected "cache hit (direct)" to be 1, got 0
cache directory /home/jcea/video/zz/zz/ccache-3.2.2/testdir.16744/.ccache
primary config /home/jcea/video/zz/zz/ccache-3.2.2/testdir.16744/.ccache/ccache.conf
secondary config (readonly) /usr/local/etc/ccache.conf
cache hit (direct) 0
cache hit (preprocessed) 0
cache miss 1
files in cache 2
cache size 8.2 kB
max cache size 5.0 GB
Test data and log file have been left in testdir.16744
Makefile:83: recipe for target 'test' failed
make: *** [test] Error 1
I get the very same result when testing in another system with gcc 4.9.2.
Thanks for the bug report. Such a segmentation fault in the test suite should be noticed by many others, so it's very strange. It would be super useful if you could help me debug this problem since I highly suspect that it's tied to your environment in some way.
The first thing to do is to find out what segfaults and the easiest is probably to run the basedir test suite like this:
sh -x test.sh basedir >test.log 2>&1
Look in test.log for the command preceding the "Segmentation fault" output. Most likely, it's the ccache invocation on line 1558 in test.sh that crashes. Is my guess correct?
Next thing to do would be to run a debugger on the core file to get a backtrace. Would that be something you could do?
Thanks in advance!
I agree that this is suspicious but I am getting the same core dump both in a Ubuntu machine and in a different Solaris machine, with different versions of GCC, etc.
After executing "sh -x test.sh basedir >test.log 2>&1" I see:
+ [ 1 != 1 ]
+ cd ..
+ cd dir2
+ CCACHE_BASEDIR=/home/jcea/video/zz/zz/ccache-3.2.2/testdir.997/dir2 /home/jcea
/video/zz/zz/ccache-3.2.2/ccache gcc -I/home/jcea/video/zz/zz/ccache-3.2.2/testd
ir.997/dir2/include -c src/test.c
+ checkstat cache hit (direct) 1
+ stat=cache hit (direct)
+ getstat cache hit (direct)
+ stat=cache hit (direct)
+ + /home/jcea/video/zz/zz/ccache-3.2.2/ccache+ cut -c34-
Running under GDB I get this:
Starting program: /home/jcea/video/zz/zz/ccache-3.2.2/ccache gcc -I/home/jcea/video/zz/zz/ccache-3.2.2/testdir.997/dir2/include -c src/test.c
Program received signal SIGSEGV, Segmentation fault.
0x000000000040ca17 in read_manifest (f=f@entry=0x61f660) at manifest.c:247
247 READ_INT(4, magic);
#0 0x000000000040ca17 in read_manifest (f=f@entry=0x61f660) at manifest.c:247
#1 0x000000000040d2c2 in manifest_get (conf=0x61f190,
manifest_path=<optimized out>) at manifest.c:634
#2 0x0000000000403a94 in calculate_object_hash (args=<optimized out>,
#3 0x0000000000406819 in ccache (argc=argc@entry=5,
argv=argv@entry=0x7fffffffe218) at ccache.c:2789
#4 0x000000000040780b in ccache_main (argc=5, argv=0x7fffffffe218)
#5 0x00007ffff75d8c8d in __libc_start_main () from /lib/libc.so.6
#6 0x0000000000404011 in _start ()
Thanks! Nothing unusual there, except of course that it crashes.
What version of libz (zlib) are you using?
Would it be possible for you to debug this further by e.g. compiling without -O2 and stepping through the execution of the ccache command on line 1565 in test.sh? Or would it be possible for me to get some temporary account on one of your systems so that I could do the same?
firstname.lastname@example.org, any thoughts on my last questions? I would love to be able to reproduce this problem.
email@example.com: Can this problem still be reproduced?
Closing this bug due to lack of feedback.
Don't hesitate to reopen the bug if there are more information.