Make sure to not write partial deps entries.
authorNico Weber <nicolasweber@gmx.de>
Fri, 14 Jun 2013 05:11:34 +0000 (22:11 -0700)
committerNico Weber <nicolasweber@gmx.de>
Fri, 14 Jun 2013 05:19:09 +0000 (22:19 -0700)
commit13bad8d61c1a1d25328ae99daf50ac71294b8bb1
tree4030f78908190d37f13aadb0ac901fb3f0b60ec9
parent75918b84f78aaca2133f21622374019cd2ef17ee
Make sure to not write partial deps entries.

When two ninja instances run in parallel in the same build directory,
one instance could write a deps entry header and a few ids, and then the
other instance could write a file name in the middle of the deps header.
When ninja reads this deps log on the next run, it will deserialize the
file name as indices, which will cause an out-of-bounds read.

(This can happen if a user runs a "compile this file" that uses ninja to
compile the current buffer in an editor, and also does a full build in a
terminal at the same time for example.)

While running two ninja instances in parallel in the same build
directory isn't a good idea, it happens to mostly work in non-deps mode:
There's redundant edge execution, but nothing crashes. This is partially
because the command log is line-buffered and a single log entry only
consists of a single line.

This change makes sure that deps entries are always written in one go,
like command log entries currently are. Running two ninja binaries in
parallel on the same build directory still isn't a great idea, but it's
less likely to lead to crashes.

See issue #595.
src/deps_log.cc