[ccache] Corrupt objects from three colliding compiles
Joel Rosdahl
joel at rosdahl.net
Sun May 9 08:41:54 MDT 2010
On 2010-05-06 22:22, Wilson Snyder wrote:
>
> Two followups.
>
> First, though not the problem I'm seeing, as I understand
> it, mkstemp isn't guaranteed to work on NFS v2 mounted
> drives. Thus I suggest including the hostname; there's
> already tmp_string() which is perfect. Patch below.
Applied.
> Second, I'm still not sure of the cause, but if I count
> bytes copied, and fail if zero bytes are moved this works
> around the issue.
Hmm. Have you tried checking gzeof/gzerror after gzread? I guess it
wouldn't hurt to act on read errors detected by zlib:
--- a/util.c
+++ b/util.c
@@ -190,6 +190,18 @@ int copy_file(const char *src, const char *dest,
int compress_dest)
return -1;
}
}
+ if (n == 0 && !gzeof(gz_in)) {
+ int errnum;
+ cc_log("gzread error: %s", gzerror(gz_in, &errnum));
+ gzclose(gz_in);
+ if (gz_out) {
+ gzclose(gz_out);
+ }
+ close(fd_out);
+ unlink(tmp_name);
+ free(tmp_name);
+ return -1;
+ }
gzclose(gz_in);
if (gz_out) {
> [...]
> One thing I wonder is the unlink() before the rename. I
> presume that is needed to prevent permission issues, but I
> wonder if it contributes to the race involving
> host1:unlink(), host1:rename(), host2:unlink(),
> host2:rename(), host3:open().
I'm not sure why there's an unlink before the rename -- it seems
redundant to me. If you remove it, do you see any improvement?
-- Joel
More information about the ccache
mailing list