Bug 9972 - ccache handing out 0 byte .o files ...
ccache handing out 0 byte .o files ...
Status: CLOSED FIXED
Product: ccache
Classification: Unclassified
Component: ccache
3.1.8
All All
: P5 major
: 3.1.10
Assigned To: Joel Rosdahl
Joel Rosdahl
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-27 09:58 UTC by Michael Meeks
Modified: 2014-10-19 18:36 UTC (History)
0 users

See Also:


Attachments
fixed up prototype patch (937 bytes, patch)
2013-08-06 13:59 UTC, Michael Meeks
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Meeks 2013-06-27 09:58:51 UTC
I had an interesting one with a partner just now - their machine had died during / shortly after compilation (I suspect) with some graphics driver lockup and hard reset. On returning all was well for some days - but (it seems) now there were several zero length (but apparently valid) files in the ccache.

Unfortunately, that meant on the next compile (of these un-changed files) - we got served up zero length .o files- which then failed to link (a zero length file is always a bad object file I think).

So - it would be just lovely to either run fsync on each file as it goes into the cache [ this was on ext4 so -in-theory- that should do some good ], and/or check for and discard zero size .o files and refuse to hand them out / clean that cache entry & force re-compilation.

Anyhow - many thanks for ccache - it saves libreoffice a ton of cycles normally ! :-)
Comment 1 Michael Meeks 2013-08-06 13:59:14 UTC
Created attachment 9111 [details]
fixed up prototype patch
Comment 2 Joel Rosdahl 2013-08-08 19:55:38 UTC
(In reply to comment #0)
> [...]
> So - it would be just lovely to either run fsync on each file as it goes into
> the cache [ this was on ext4 so -in-theory- that should do some good ],

fsyncing each file would be way to slow, unfortunately.

> and/or
> check for and discard zero size .o files and refuse to hand them out / clean
> that cache entry & force re-compilation.

That sounds like a good idea, though!
Comment 3 Joel Rosdahl 2013-08-08 20:09:05 UTC
(In reply to comment #1)
> Created attachment 9111 [details]
> fixed up prototype patch

Thanks. I ported and applied your patch to the maint branch in 12e2badf739244dc97cad84a6fb1905ec3c4a76d (note "badf" in the hash - it's obviously a commit that fixes bad files...).
Comment 4 Michael Meeks 2013-08-09 05:15:33 UTC
Thanks for the merge ! :-) I love the badf.

FWIW - my experience of file-data corruption under the tender ministrations of non-fsynched ext4 file-systems is that you usually end up with perfect meta-data, and (usually zero) data. So - for the next round of improvement I guess that reading the first 16 bytes or so and checking they're not all zero's might also be a useful check [ and presumably with only a small perf. impact ]. I've not seen that happen yet though in the wild.

Anyhow - thanks for ccache ... :-)
Comment 5 Joel Rosdahl 2014-10-19 18:36:15 UTC
Fix included in v3.1.10.