Hello Ludovic, Maxim Cournoyer writes: > Hello again! > > Maxim Cournoyer writes: > >> Hello! >> >> Ludovic Courtès 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) :-).