[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