bug#17591: Offload hook fails to send files

[Ludovic Courtès]

address@hidden (Ludovic Courtès) skribis:

> 21927 write(10, 
> "\1\0\0\0\0\0\0\0\0000\213\1\0\0\0\0nix-archive-1\0\0\0\1\0\0\0\0\0\0\0 
> address@hidden (guix build \2000\213\1\0\0\0\0d-system) (guix build 
> ut\2400\213\1\0\0\0\0efine %output (getenv \"o\3000\213\1\0\0\0\0efine 
> %outputs (map (lam\3400"..., 11072 <unfinished ...>
> 21925 <... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 
> 21926
>
> It reads 11072 bytes (as expected) from stdin, but by the time it writes
> them on the socket (the last write(10, ...) call), those 11072 bytes got
> corrupted.
>
> The above snippet corresponds to this part of store.scm:
>
>           ((= k %stderr-read)
>            ;; Read a byte stream from USER-PORT.
>            (let* ((max-len (read-int p))
>                   (data    (get-bytevector-n user-port max-len))
>                   (len     (bytevector-length data)))
>              (write-int len p)
>              (put-bytevector p data)
>              (write-padding len p)
>              #f))
>
> where ‘data’ is the corrupted bytevector.
>
> The good news is that I can reproduce it like this:
>
> $ guix archive --export $(guix build -d coreutils) > t.nar
> $ while guix archive --import <t.nar ; do : ; done

The problem comes from the ‘get-bytevector-n’ call above, and
specifically the ‘scm_c_shrink_bytevector’ and ‘GC_REALLOC’ calls it
entails.  If we change that to, say, ‘scm_make_bytevector’ (in
libguile), then the problem goes away.

So that looks like a GC_REALLOC bug (in libgc 7.4.0 and 7.2d at least),
but unfortunately I’ve been unable to reduce it further (neither in
Scheme nor in C.)

On the Guix side, commit 5895f24 works around the problem.  Now we need
a workaround in libguile, and ideally a proper bug report for libgc.

(I’ll close this bug when we confirm that it solves the problem on
Hydra.)

Ludo’.