Re: [ccache] ccache interrupt handling bug
"Nadav Har'El" writes: > One thing you should perhaps consider is whether this change (using > sigaction, signal sets, instead of the antique signal(), etc.) might break > compilation on some antique UNIX machines or on MS-Windows (!?) or > something. But I doubt any present-day system actually lacks sigaction() > and friends, so I think your code is good. Windows is definitely a risk factor here: AFAIK they don't provide a decent emulation of the POSIX signal functions. However, they don't have the BSD ones either, so I assume ccache is already covering Windows specially. As for the "antique UNIX" angle, I can offer a data point: Postgres still nominally carries support for the pre-POSIX signal API, but AFAICT that code isn't being used on any platform still in use. *All* of the active non-Windows members of our buildfarm report that their configure test for POSIX signals succeeds. And there are some pretty darn old systems in there: http://buildfarm.postgresql.org/cgi-bin/show_status.pl regards, tom lane ___ ccache mailing list ccache@lists.samba.org https://lists.samba.org/mailman/listinfo/ccache
Re: [ccache] ccache interrupt handling bug
Joel Rosdahl writes: > Tom Lane wrote: >> Actually, that's a bug not just a cosmetic problem, because it introduces >> a race condition. > Yes, sounds like a race condition that could happen. > I just pushed this change as a fix: > https://git.samba.org/?p=ccache.git;a=commitdiff;h=4fdb9580fedac9669508bef0837f46f1e9310e24. > Opinions on it are welcome. Hm. In principle there are still race conditions here: consider what happens if the SIGINT is received between fork() and storing the PID into *pid, or after waitpid() and before clearing *pid. Those windows are probably narrow enough to not be an issue in practice, but it's a bit nervous-making. One thing that might be worth doing is declaring pid (and hence the pointer argument) to be volatile so that the compiler wouldn't be tempted to rearrange the code and maybe make those windows bigger. That's required for formal C-spec-compliance anyway, given that pid is accessed by a signal handler. regards, tom lane ___ ccache mailing list ccache@lists.samba.org https://lists.samba.org/mailman/listinfo/ccache
Re: [ccache] ccache version 3.2.3 has been released
Joel Rosdahl writes:
> Tom Lane wrote:
>> [...] this fails to build for me on late-model OS X:
> Bummer. Here's my proposed fix:
> https://git.samba.org/?p=ccache.git;a=commitdiff;h=f74c76107933046309861680b741adc67ac2a34e.
> Perhaps you could try it out?
Yup, that seems to work as expected on OS X Yosemite, either
with or without --with-bundled-zlib. Thanks!
regards, tom lane
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache
Re: [ccache] Compiler warnings in ccache 3.2.3
Joel Rosdahl writes: >> I got a few warnings about assignments of pointers to "bool" values. I >> think these are legitimate gripes, because on platforms where bool is only >> a byte wide, the net effect will be to assign the pointer's low-order byte >> to the bool. > Well, as I interpret the C99 standard, bool from stdbool.h (AKA _Bool) is > guaranteed to only contain 1 or 0: ... > However, ccache's system.h has fallback code on systems that don't have > stdbool.h and then a bool can be typedef-ed to be a signed char, which is > something I didn't think of when writing the code in question. (I guess you > are on such an "antique" non-C99 system?) Ah, right, that explains why I only saw the warnings on a pretty old box. regards, tom lane ___ ccache mailing list ccache@lists.samba.org https://lists.samba.org/mailman/listinfo/ccache
Re: [ccache] ccache version 3.2.3 has been released
Mike Frysinger writes: > On 16 Aug 2015 13:39, Tom Lane wrote: >> and of course "-lz" isn't a valid dependency. > that's not really true. make will expand it internally into paths like > /usr/lib/libz.so. Hmm ... there may be versions of make for which that's true, but Apple's version (which is gnu make 3.81) does not like it. regards, tom lane ___ ccache mailing list ccache@lists.samba.org https://lists.samba.org/mailman/listinfo/ccache
Re: [ccache] ccache interrupt handling bug
"Nadav Har'El" writes:
> On Mon, Aug 17, 2015 at 12:50 AM, Tom Lane wrote:
>> * make launches "ccache gcc -o test.o test.c"
>> * user types control-C
>> * ccache receives SIGINT and exits
>> * make does unlink("test.o") to clean up after failed compile step, which
>> it thinks is done
>> * gcc creates test.o
> Stupid question: Does ccache let gcc write to test.o directly, or does it
> write to some temporary file and then ccache copies it?
Dunno, but that just moves the problem somewhere else no? For instance,
in the code fragment you mentioned, I wonder whether it's sane to do
"clean_up_pending_tmp_files();" when gcc is still on the loose.
regards, tom lane
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache
Re: [ccache] ccache interrupt handling bug
"Nadav Har'El" writes:
> First of all, thanks. This indeed fixes the bug, and is exactly the first
> patch I tried to fix it this problem.
> I want to explain, though, why I ended up sending a different patch for
> this problem - a 4-line patch instead of this one-liner. The explanation is
> not very important, and I should probably have done this earlier, but
> perhaps someone would find it interesting.
> When the user types ^C, the operating system sends SIGINT to all processes
> belonging to the terminal's process group - and in particular it sends
> SIGINT to *both* the child compiler and ccache, separately.
> Your patch makes ccache exit as soon as it gets the SIGINT - but the child
> compiler might still be running for a while longer. This will usually be
> fine, but I thought the user can be surprised if he sees ccache (which he
> considers to be the compiler) exit, but "ps" shows the compiler is still
> running. This would be especially annoying if some hypothetical compiler
> trapped SIGINT deliberately, and continued to run long after ccache exits.
Actually, that's a bug not just a cosmetic problem, because it introduces
a race condition. Consider this sequence of events:
* make launches "ccache gcc -o test.o test.c"
* user types control-C
* ccache receives SIGINT and exits
* make does unlink("test.o") to clean up after failed compile step, which
it thinks is done
* gcc creates test.o
* gcc receives SIGINT and exits
We're left with a probably-broken test.o in the filesystem, despite
make's attempt to clean up. Now, the window for this is pretty narrow,
but I think it could happen: I don't believe that sending signals to
multiple processes is atomic in most kernels.
You really don't want ccache to exit until after all externally-observable
things have stopped happening. (I recently fixed a somewhat related bug
in Postgres :-(, which is why this caught my eye.)
regards, tom lane
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache
[ccache] Compiler warnings in ccache 3.2.3
I got a few warnings about assignments of pointers to "bool" values.
I think these are legitimate gripes, because on platforms where bool
is only a byte wide, the net effect will be to assign the pointer's
low-order byte to the bool. There's at least a 1-in-256 chance of
a non-null pointer erroneously converting to a "false" boolean value
(maybe more than that, if the pointer is likely to be aligned ...).
I propose the attached patches to fix this.
regards, tom lane
diff -c -r orig/ccache-3.2.3/ccache.c ccache-3.2.3/ccache.c
*** orig/ccache-3.2.3/ccache.c Sun Aug 16 08:12:05 2015
--- ccache-3.2.3/ccache.c Sun Aug 16 14:59:46 2015
***
*** 1263,1269
compiler_is_clang(struct args *args)
{
char *name = basename(args->argv[0]);
! bool is = strstr(name, "clang");
free(name);
return is;
}
--- 1263,1269
compiler_is_clang(struct args *args)
{
char *name = basename(args->argv[0]);
! bool is = strstr(name, "clang") != NULL;
free(name);
return is;
}
diff -c -r orig/ccache-3.2.3/conf.c ccache-3.2.3/conf.c
*** orig/ccache-3.2.3/conf.c Sun Aug 16 08:12:05 2015
--- ccache-3.2.3/conf.c Sun Aug 16 15:01:12 2015
***
*** 58,64
char **value = (char **)result;
free(*value);
*value = subst_env_in_string(str, errmsg);
! return *value;
}
static bool
--- 58,64
char **value = (char **)result;
free(*value);
*value = subst_env_in_string(str, errmsg);
! return *value != NULL;
}
static bool
diff -c -r orig/ccache-3.2.3/language.c ccache-3.2.3/language.c
*** orig/ccache-3.2.3/language.c Sun Aug 16 08:12:05 2015
--- ccache-3.2.3/language.c Sun Aug 16 15:01:01 2015
***
*** 149,155
bool
language_is_supported(const char *language)
{
! return p_language_for_language(language);
}
bool
--- 149,155
bool
language_is_supported(const char *language)
{
! return p_language_for_language(language) != NULL;
}
bool
diff -c -r orig/ccache-3.2.3/util.c ccache-3.2.3/util.c
*** orig/ccache-3.2.3/util.c Sun Aug 16 08:12:05 2015
--- ccache-3.2.3/util.c Sun Aug 16 15:00:41 2015
***
*** 1638,1644
if (curly) {
if (*q != '}') {
*errmsg = format("syntax error: missing '}' after \"%s\"", p);
! return NULL;
}
}
--- 1638,1644
if (curly) {
if (*q != '}') {
*errmsg = format("syntax error: missing '}' after \"%s\"", p);
! return false;
}
}
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache
Re: [ccache] ccache version 3.2.3 has been released
Joel Rosdahl writes:
> I'm happy to announce ccache version 3.2.3.
Hate to be the bearer of bad news, but this fails to build for me on
late-model OS X:
$ ./configure
$ make
gcc -DHAVE_CONFIG_H -DSYSCONFDIR=/usr/local/etc -I. -I. -g -O2 -Wall -W -c -o
main.o main.c
...
gcc -DHAVE_CONFIG_H -DSYSCONFDIR=/usr/local/etc -I. -I. -g -O2 -Wall -W -c -o
conf.o conf.c
make: *** No rule to make target `-lz', needed by `ccache'. Stop.
The reason appears to be that the Makefile gets generated like so:
$ grep extra_libs Makefile
extra_libs = -lz
ccache$(EXEEXT): $(ccache_objs) $(extra_libs)
$(CC) $(all_cflags) -o $@ $(ccache_objs) $(all_ldflags) $(extra_libs)
$(LIBS)
test/main$(EXEEXT): $(base_objs) $(test_objs) $(extra_libs)
$(CC) $(all_cflags) -o $@ $(base_objs) $(test_objs) $(all_ldflags)
$(extra_libs) $(LIBS)
and of course "-lz" isn't a valid dependency. Manually removing
$(extra_libs) from these two dependency lists fixes it.
I do not recall having had this problem the last time I built ccache,
but that was 3.2.1, so I don't know whether it was introduced in
3.2.2 or 3.2.3.
regards, tom lane
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache
Re: [ccache] MacOSX: cache losing clang/llvm debug symbols with separate compilation…
Christophe de Dinechin writes:
> Apparently, ccache loses debug symbols on Mavericks with clang/lldb. Here is
> a session illustrating the problem. I spent quite a bit of time figuring out
> that ccache was the culprit, so I thought I'd share also on the clang and
> LLVM mailing lists in case someone else runs into this.
FWIW, ccache and lldb seem to play together nicely for me, so I guess
there's some other contributing factor in your case. I'm using:
OSX 10.9.4
lldb 310.2.37 (from Xcode 5.1.1)
self-compiled ccache 3.1.9
regards, tom lane
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache
Re: [ccache] ccache has issues with current Apple compilers
Lubos Lunak writes: > Use CCACHE_CPP2 when using ccache with clang (see e.g. > http://www.mail-archive.com/ccache@lists.samba.org/msg01045.html). Indeed, that seems to do the trick. Thanks! regards, tom lane ___ ccache mailing list ccache@lists.samba.org https://lists.samba.org/mailman/listinfo/ccache
[ccache] ccache has issues with current Apple compilers
I tried to install ccache 3.1.9 on a current Mac system (OS X 10.9.3,
Xcode 5.1.1). Configure and compile went cleanly, with the exception
of two probably-harmless warnings:
manifest.c:223:2: warning: shift count >= width of type [-Wshift-count-overflow]
READ_INT(1, version);
^~~~
manifest.c:150:10: note: expanded from macro 'READ_INT'
(var) <<= 8; \
^ ~
manifest.c:230:2: warning: shift count >= width of type [-Wshift-count-overflow]
READ_INT(1, mf->hash_size);
^~
manifest.c:150:10: note: expanded from macro 'READ_INT'
(var) <<= 8; \
^ ~
2 warnings generated.
I made this change to silence that, since I think that the C standard
allows compilers to consider the case undefined behavior:
$ diff -c manifest.c~ manifest.c
*** manifest.c~ Sun Jan 6 11:57:59 2013
--- manifest.c Sat May 31 13:42:53 2014
***
*** 147,154
if (ch_ == EOF) { \
goto error; \
} \
! (var) <<= 8; \
! (var) |= ch_ & 0xFF; \
} \
} while (0)
--- 147,153
if (ch_ == EOF) { \
goto error; \
} \
! (var) = (((unsigned int) (var)) << 8) | (ch_ & 0xFF); \
} \
} while (0)
but it's probably not really an issue. However, "make test" refuses
to do anything much:
...
PASSED: 178 assertions, 64 tests, 9 suites
CC='gcc' ./test.sh
WARNING: Compiler gcc not supported (version: Configured with:
--prefix=/Applications/Xcode.app/Contents/Developer/usr
--with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/c++/4.2.1)
-- not running tests
I looked at test.sh and concluded that it simply didn't recognize the
output of "gcc --version", which looks like this:
$ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr
--with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/c++/4.2.1
Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin13.2.0
Thread model: posix
So I diked out that check from the test script and tried again.
The first half dozen test suites went OK, but in the "basedir"
testsuite I got a lot of chatter:
clang: warning: argument unused during compilation: '-I
/Users/tgl/src/ccache-3.1.9/testdir.20963/dir1/include'
clang: warning: argument unused during compilation: '-I
/Users/tgl/src/ccache-3.1.9/testdir.20963/dir2/include'
clang: warning: argument unused during compilation: '-I include'
clang: warning: argument unused during compilation: '-I include'
clang: warning: argument unused during compilation: '-I include'
[ much more in the same vein... ]
and then the "pch" testsuite failed altogether:
starting testsuite pch
SUITE: "pch", TEST: "no -fpch-preprocess, -include" - Expected "cache miss" to
be 1, got 0
cache directory
/Users/tgl/src/ccache-3.1.9/testdir.20963/.ccache
cache hit (direct) 0
cache hit (preprocessed) 0
cache miss 0
preprocessor error 1
files in cache 0
cache size 0 Kbytes
max cache size 1.0 Gbytes
TEST FAILED
Test data and log file have been left in testdir.20963
make: *** [test] Error 1
I did some further experiments and concluded that ccache is in fact kind
of broken: when I try to compile a large project with it, I get thousands
of weird warnings that do not appear when using gcc directly (many of them
the same kind of "unused -I argument" bleat shown above, but others are
warnings about C constructs that I don't normally see any warnings about).
The resulting executables seem to work, but I can't use a toolchain that's
this noisy. In any case, surely it's unexpected that ccache would change
the compiler's warning behavior?
I don't know enough about ccache to debug this, but will be happy
to supply further info if given directions how to get it.
(BTW, I successfully installed the same ccache source code on two
older Apple systems, and it's working as expected there.)
regards, tom lane
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache
