GNU bug report logs - #43518
(guix status) occasionally crashes when max-jobs > 1

Previous Next

Full log

View this message in rfc822 format

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 43518 <at> debbugs.gnu.org
Subject: bug#43518: Guix substitute crash in procedure raise-exception: wrong type agument in position 1: #f
Date: Tue, 01 Dec 2020 12:23:29 -0500

[Message part 1 (text/plain, inline)]

Hello Ludovic,

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

> Hello again!
>
> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:
>
>> Hello!
>>
>> Ludovic Courtès <ludo <at> 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.

The trace attached is even better, in that it triggered the problem!  I
don't have time to take a look now, but I hope it'll be useful in
understanding the issue better.  It's rather precious (quite some luck
seems to be needed to reproduce) :-).

[log.precious (text/plain, attachment)]

[Message part 3 (text/plain, inline)]

Thanks,

Maxim

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.