bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#43518: Guix substitute crash in procedure raise-exception: wrong typ


From: Maxim Cournoyer
Subject: bug#43518: Guix substitute crash in procedure raise-exception: wrong type agument in position 1: #f
Date: Sun, 04 Oct 2020 07:53:47 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)

Hello again!

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

> Hello!
>
> Ludovic Courtès <ludo@gnu.org> writes:
>
> [...]
>
>> The “@ download-progress” line is printed by (guix scripts substitute)
>> and later consumed by (guix status) in the client, which is why I
>> mentioned ‘progress-reporter/trace’ above.
>>
>> I think the problem we’re looking at could occur if those traces are not
>> printed in an atomic way, and thus (guix status) gets to see
>> truncated/mixed up traces.  So I tried this:
>>
>>   _NIX_OPTIONS=print-extended-build-trace=1 sudo -E \
>>     ./pre-inst-env strace -s 200 -o ,,s  guix substitute \
>>        --substitute 
>> /gnu/store/pknm43xsza6nlc7bn27djip8fis92akd-gcc-toolchain-10.2.0 /tmp/t.drv
>>
>> It shows that traces are printed in a single write(2) call:
>>
>> write(2, "@ download-progress /tmp/t.drv 
>> http://ci.guix.gnu.org/nar/lzip/pknm43xsza6nlc7bn27djip8fis92akd-gcc-toolchain-10.2.0
>>  4843 4843\n", 127) = 127
>>
>> So this side of things seems to be good.  But then traces could be
>> mangled/truncated by the daemon maybe.  An strace log of the failing
>> case would be very helpful.

[...]

I managed to capture two instances of 'transferred= #f' from my pk
output in the attached logs.  Curiously, they didn't lead to the crash.
Attached is a pruned version of the strace log of a command like
'./pre-inst-env guix package -m my-manifest --max-jobs=20'.  Offloading
was in use.

Attachment: log.pruned.lz
Description: strace log with two instances of 'transferred= #f'

Thanks,

Maxim

reply via email to

[Prev in Thread] Current Thread [Next in Thread]