bug#19671: Raw binary data in build log from substitute-binary

bug#19671: Raw binary data in build log from substitute-binary

[Mark H Weaver]

[-- Attachment #1: Type: text/plain, Size: 327 bytes --]

While trying to install 'racket' using substitutes, several lines of the
form "substitute-binary: <binary garbage>" were output.  See the
attachment for the precise output, captured via Emacs' shell mode.

This was when running guix from git commit 2dfed64 on an i686 GSD
system.

Any ideas what would cause this?

      Mark


[-- Attachment #2: transcript of output --]
[-- Type: application/octet-stream, Size: 9421 bytes --]

bug#19671: Raw binary data in build log from substitute-binary

[Mark H Weaver]

[-- Attachment #1: Type: text/plain, Size: 796 bytes --]

Mark H Weaver <mhw@netris.org> writes:

> While trying to install 'racket' using substitutes, several lines of the
> form "substitute-binary: <binary garbage>" were output.  See the
> attachment for the precise output, captured via Emacs' shell mode.
>
> This was when running guix from git commit 2dfed64 on an i686 GSD
> system.

The same problem happened to me again, this time on git commit 710f3ce,
while running 'guix system build'.  I've attached another transcript.

The binary junk is immediately followed (with no intervening newline) by
the message:

http://hydra.gnu.org/2zadn0b2kljwlsyarr3j5rz44yi2pvs3.narinfo' failed: 502, "Bad Gateway"

This suggests that nginx had a problem fetching it from hydra-server on
port 3000.  Repeating the same command worked properly.

       Mark



[-- Attachment #2: Another example of binary output from substitute-binary --]
[-- Type: application/octet-stream, Size: 8156 bytes --]

bug#19671: Raw binary data in build log from substitute-binary

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> Mark H Weaver <mhw@netris.org> writes:
>
>> While trying to install 'racket' using substitutes, several lines of the
>> form "substitute-binary: <binary garbage>" were output.  See the
>> attachment for the precise output, captured via Emacs' shell mode.
>>
>> This was when running guix from git commit 2dfed64 on an i686 GSD
>> system.
>
> The same problem happened to me again, this time on git commit 710f3ce,
> while running 'guix system build'.  I've attached another transcript.
>
> The binary junk is immediately followed (with no intervening newline) by
> the message:
>
> http://hydra.gnu.org/2zadn0b2kljwlsyarr3j5rz44yi2pvs3.narinfo' failed: 502, "Bad Gateway"
>
> This suggests that nginx had a problem fetching it from hydra-server on
> port 3000.  Repeating the same command worked properly.

I don’t see how the binary garbage could reach the stdout of ‘guix
substitute-binary’.  This happens when hydra.gnu.org is overloaded as
you suggest, so perhaps we have a connection closed unexpected or
something like that, but still.

Since this is the multithreaded ‘substitute-binary’, could there be
something fishy going on in wrt. threads?

Ludo’.

bug#19671: Raw binary data in build log from substitute-binary

[Ludovic Courtès]

This has just happened to me as well, and I think the reason is that,
when a download failure happens (500, 502, 504, etc.), the thread doing
the download directly writes to the current error port.

And as we know, ports are not thread-safe in Guile 2.0 and we’re not
doing additional synchronization here, so everything wrecks havoc.

This is another incentive to merge wip-http-pipelining.  I’ll give it
another try.

Thanks,
Ludo’.

bug#19671: Raw binary data in build log from substitute-binary

[Ludovic Courtès]

ludo@gnu.org (Ludovic Courtès) skribis:

> This has just happened to me as well, and I think the reason is that,
> when a download failure happens (500, 502, 504, etc.), the thread doing
> the download directly writes to the current error port.
>
> And as we know, ports are not thread-safe in Guile 2.0 and we’re not
> doing additional synchronization here, so everything wrecks havoc.
>
> This is another incentive to merge wip-http-pipelining.  I’ll give it
> another try.

This was done in d3a6520, so closing this bug.

Ludo’.