bug#41362: error when running guix pull on i686-linux

bug#41362: error when running guix pull on i686-linux

[Mayeul Cantan]

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

Hello there,

I am having some trouble building the latest generation (f2e99d9) on my 
old samsung n130 (i686).

Here is the console output:

root@charon ~# guix pull
Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
Building from this channel:
guix https://git.savannah.gnu.org/git/guix.git f2e99d9
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 
100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 
100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 
100.0%
building 
/gnu/store/3yjm93pizc6pnggdvyl17ynajv51448j-module-import.drv...
building 
/gnu/store/gc643vn38kb53zqlhr5nvgwsqhi9sbr5-module-import-compiled.drv...
4% [##### ]builder for 
`/gnu/store/gc643vn38kb53zqlhr5nvgwsqhi9sbr5-module-import-compiled.drv' 
failed with exit code 1
build of 
/gnu/store/gc643vn38kb53zqlhr5nvgwsqhi9sbr5-module-import-compiled.drv 
failed
View build log at 
'/var/log/guix/drvs/gc/643vn38kb53zqlhr5nvgwsqhi9sbr5-module-import-compiled.drv.bz2'.
cannot build derivation 
`/gnu/store/9sn1078n6nkdskpsa8wibbb19fgjl2a7-compute-guix-derivation.drv': 
1 dependencies couldn't be built
guix pull: error: build of 
`/gnu/store/9sn1078n6nkdskpsa8wibbb19fgjl2a7-compute-guix-derivation.drv' 
failed

Attached are two log files from two successive attempts at running `guix 
pull`. I'm often having isues pulling the latest derivations on that 
computer, and currently sitting at 
f0da92cb42f99cddadd9cea373758355cb7c6351 (though I've also had issues 
before that specific one).

I've been interacting with mbakke on the matrix channel regarding this 
since yesterday.

We tried bisecting the issue, and found an unlikely culprit in the name 
of 694e10af639da64cdf6f1c44cadf9a64f8a04fa6

However, I had interupted guix pull when it seemed to progress further, 
assuming the commit was good. And when trying to build  the commit right 
before, I encountered another, somewhat similar error (also attached: 
wy793 something).

After checking that 9d0b9c7c6c0b0d45653dea80b499314ea415d3c7 (just after 
the one I was on) worked all right, I tried a second bissect, that found 
10c413685f13af12fa2bb34796db82e1f52b47af as a possible cause. After 
reverting just 10c41 failed, I also reverted 694e10 on top of that. I 
thought it had worked as it kept building, but it failed after a while 
(slightly different log: gi046...). During that build phase, a lot of 
these "unbound variable  \x0" kept being printed to stdout, but I have a 
limited scrollback and forgot to tee it to a file beforehand. I could 
still obtain it if it was necessary.

I am not sure what to try next? I could try a script that sequencially 
builds every commit and prints the ones that succeed and the one that do 
not, but I wouldn't mind if you had better ideas, especially as a 
successful build can take a few hours to complete.

Thanks for your work, and sorry for this bug report that's a bit unclear 
and confused,

Mayeul

[-- Attachment #2: attempt2-643vn38kb53zqlhr5nvgwsqhi9sbr5-module-import-compiled.drv.bz2 --]
[-- Type: application/x-bzip2, Size: 720 bytes --]

[-- Attachment #3: 643vn38kb53zqlhr5nvgwsqhi9sbr5-module-import-compiled.drv.bz2 --]
[-- Type: application/x-bzip2, Size: 719 bytes --]

[-- Attachment #4: wy793d3r1q4qglfvfklsf8c6virby4-guix-system.drv.bz2 --]
[-- Type: application/x-bzip2, Size: 633 bytes --]

[-- Attachment #5: gi046wfj8qdasv9n78ish87aphffwj-guix-extra.drv.bz2 --]
[-- Type: application/x-bzip2, Size: 1348 bytes --]

bug#41362: error when running guix pull on i686-linux

[Ludovic Courtès]

Hi,

Mayeul Cantan <oss+guix@mayeul.net> skribis:

> After checking that 9d0b9c7c6c0b0d45653dea80b499314ea415d3c7 (just
> after the one I was on) worked all right, I tried a second bissect,
> that found 10c413685f13af12fa2bb34796db82e1f52b47af as a possible
> cause. After reverting just 10c41 failed, I also reverted 694e10 on
> top of that. I thought it had worked as it kept building, but it
> failed after a while (slightly different log: gi046...). During that
> build phase, a lot of these "unbound variable  \x0" kept being printed
> to stdout, but I have a limited scrollback and forgot to tee it to a
> file beforehand. I could still obtain it if it was necessary.

The module-imported-compiled build log you provided shows this:

--8<---------------cut here---------------start------------->8---
[ 1/84] Loading './gcrypt/hash.scm'...
[ 2/84] Loading './git.scm'...
[ 3/84] Loading './gnu/packages/bootstrap.scm'...
Backtrace:
          19 (primitive-load-path "gnu/packages" #<procedure 840a8a0?>)
In ice-9/eval.scm:
   721:20 18 (primitive-eval _)
In ice-9/psyntax.scm:
  1262:36 17 (expand-top-sequence _ _ _ #f _ _ _)
  1209:24 16 (parse _ (("placeholder" placeholder)) ((top) #(# # ?)) ?)
   285:10 15 (parse _ (("placeholder" placeholder)) (()) _ c&e (eval) ?)
In ice-9/eval.scm:
   293:34 14 (_ #<module (#{ g73}#) 81c5870>)
In ice-9/boot-9.scm:
   2874:4 13 (define-module* _ #:filename _ #:pure _ #:version _ # _ ?)
  2887:24 12 (_)
   222:29 11 (map1 _)
   222:17 10 (map1 (((guix ui)) ((guix utils)) ((guix discovery)) # ?))
  2800:17  9 (resolve-interface (guix ui) #:select _ #:hide _ # _ # _ ?)
In ice-9/threads.scm:
    390:8  8 (_ _)
In ice-9/boot-9.scm:
  2726:13  7 (_)
In ice-9/threads.scm:
    390:8  6 (_ _)
In ice-9/boot-9.scm:
  2994:20  5 (_)
   2312:4  4 (save-module-excursion _)
  3014:26  3 (_)
In unknown file:
           2 (primitive-load-path "guix/ui" #<procedure 8769de0 at i?>)
In ice-9/eval.scm:
   223:20  1 (proc #<module (#{ g268}#) 8871140>)
In unknown file:
           0 (%resolve-variable (7 . #) #<module (#{ g268}#) 8871140>)

ERROR: In procedure %resolve-variable:
Unbound variable: #{\x0;\x0;\x0;\x0;\x0; […]
--8<---------------cut here---------------end--------------->8---

This hints at a possible memory corruption issue in Guile, especially
since it seems to be non-deterministic.

That said, I successfully run:

  $ guix pull -s i686-linux -p /tmp/test
  […]
  $ /tmp/test/bin/guix describe
  Generacio 1     May 29 2020 18:00:54    (nuna)
    guix 9ff667e
      repository URL: https://git.savannah.gnu.org/git/guix.git
      branch: master
      commit: 9ff667ea05d0807b4e6512c92914ae517b9ec755

Most derivations were built locally.  It’s on an x86_64 laptop, though.

Is it still crashy for you?

Thanks,
Ludo’.

bug#41362: error when running guix pull on i686-linux

[Ludovic Courtès]

Hi Mayeul,

Does this bug still show up for you?

  https://issues.guix.gnu.org/41362

TIA,
Ludo’.

bug#41362: error when running guix pull on i686-linux

[Mayeul Cantan]

> Does this bug still show up for you?
> 
>    https://issues.guix.gnu.org/41362
>

Hi Ludo,

Thanks to your comment regarding a possible memory corruption issue, I 
ran my memory module trough memtest86+, which identified several 
problematic addresses. So this was likely a hardware issue.

I tried blacklisting them with the memmap kernel command-line option, 
but that didn't fix the issue. Looking at the addresses, I reduced my 
memory to 600 MiBs (mem=600M, which seems to solve the issue, though it 
makes `guix pull` extremely slow.

I haven't touched that system in a while, so my recollection is a bit 
fuzzy. I am going to try again, though. (I would have loved to 
experiment on another computer on top of another distro, but wasn't 
ready to give guix root access back then).

I think this really was a HW issue, but I will keep you posted.

Thank you for your answers,

Mayeul

-- 

Mayeul Cantan

CPE Lyon Electronics Engineer
PhD student at the Lyon Institute of Nanotechnology
+33 6 43 50 36 25

bug#41362: error when running guix pull on i686-linux

[Ludovic Courtès]

Hello,

Mayeul Cantan <oss+guix@mayeul.net> skribis:

> Thanks to your comment regarding a possible memory corruption issue, I
> ran my memory module trough memtest86+, which identified several
> problematic addresses. So this was likely a hardware issue.
>
> I tried blacklisting them with the memmap kernel command-line option,
> but that didn't fix the issue. Looking at the addresses, I reduced my
> memory to 600 MiBs (mem=600M, which seems to solve the issue, though
> it makes `guix pull` extremely slow.
>
> I haven't touched that system in a while, so my recollection is a bit
> fuzzy. I am going to try again, though. (I would have loved to
> experiment on another computer on top of another distro, but wasn't
> ready to give guix root access back then).
>
> I think this really was a HW issue, but I will keep you posted.

It does look like a hardware issue from what you describe.

Thanks for the update,
Ludo’.