From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark H Weaver Subject: Re: Grafting fails for latest Go release candidate Date: Mon, 31 Jul 2017 12:22:23 -0400 Message-ID: <87d18gzidc.fsf@netris.org> References: <20170731143925.GA19814@jasmine.lan> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:39558) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dcDSq-0004uL-LJ for guix-devel@gnu.org; Mon, 31 Jul 2017 12:22:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dcDSn-0005Tw-9L for guix-devel@gnu.org; Mon, 31 Jul 2017 12:22:40 -0400 In-Reply-To: <20170731143925.GA19814@jasmine.lan> (Leo Famulari's message of "Mon, 31 Jul 2017 10:39:25 -0400") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Leo Famulari Cc: guix-devel@gnu.org [Adding Ludovic to the CC] Leo Famulari 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