Re: Grafting fails for latest Go release candidate

[Mark H Weaver <mhw@netris.org>]

[Adding Ludovic to the CC]

Leo Famulari <leo@famulari.name> writes:

> Working on the Go package, I found that the grafting procedure fails in
> a way that I don't understand:
>
> ------
> $ ./pre-inst-env guix build go@1.9
> The following derivation will be built:
>    /gnu/store/bv30jxzjl7c5z3hk6pmywpzwwrn1hq5m-go-1.9rc1.drv
> @ build-started
> /gnu/store/bv30jxzjl7c5z3hk6pmywpzwwrn1hq5m-go-1.9rc1.drv -
> x86_64-linux
> /var/log/guix/drvs/bv//30jxzjl7c5z3hk6pmywpzwwrn1hq5m-go-1.9rc1.drv.bz2
> grafting '/gnu/store/8zbi5rr5q2pxksfgpxq37m60nsa21d3v-go-1.9rc1-doc' -> '/gnu/store/6v24sf0b3hgyc80b4w2yvx1aw03zinw6-go-1.9rc1-doc'...
> grafting '/gnu/store/73fvsx0qizcrbajgjwn8mkzkpxa6abx4-go-1.9rc1' -> '/gnu/store/ghg75mjw3csiv9hf7q0cxrm1g0fx5d0k-go-1.9rc1'...
> ERROR: In procedure put-bytevector: Value out of range: 0

I looked into this a bit.  As far as I can tell, the only way that (guix
build graft) could cause 'put-bytevector' to generate this error is if
it's called with four arguments, and the fourth argument (count) is 0,
and the third argument (start) is greater than the length of the
bytevector.

I don't have time right now to complete my analysis, but my strong
suspicion is that the following commit introduced this bug:

  https://git.savannah.gnu.org/cgit/guix.git/commit/?id=57bdd79e485801ccf405ca7389bd099809fe5d67

Specifically, I believe that it mishandles the case where the
end-of-buffer falls within the human-readable part of the store file
name, i.e. if it's within the "eeeeeeeeeeeeeeee" part of the following
example hash:

  /gnu/store/bv30jxzjl7c5z3hk6pmywpzwwrn1hq5m-eeeeeeeeeeeeeeee

The original grafting code that I wrote only rewrote the hashes, and
ensured that the entire hash was present within the buffer.  This
guaranteed that after writing the replacement hash, that the scan
position was still within the buffer.

After the modifications of the commit cited above, when a hash to be
replaced is found, the entire replacement string, including the
human-readable part, is written.  This may leave the scan pointer beyond
the end of the buffer.  It would take some more thought to determine
what happens after that, but I doubt that it's handled properly and it
seems plausible that it could lead to this error.

       Mark