error when running guix pull on i686-linux

  • Done
  • quality assurance status badge
Details
2 participants
  • Ludovic Courtès
  • Mayeul Cantan
Owner
unassigned
Submitted by
Mayeul Cantan
Severity
important
M
M
Mayeul Cantan wrote on 17 May 2020 15:16
(address . bug-guix@gnu.org)
f939f5b6a2b43a814ee6e5b05f9ca798@mayeul.net
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
Building from this channel:
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: file (.00 MiB)
Attachment: 643vn38kb53zqlhr5nvgwsqhi9sbr5-module-import-compiled.drv.bz2 (.00 MiB)
Attachment: wy793d3r1q4qglfvfklsf8c6virby4-guix-system.drv.bz2 (.00 MiB)
Attachment: gi046wfj8qdasv9n78ish87aphffwj-guix-extra.drv.bz2 (.00 MiB)
L
L
Ludovic Courtès wrote on 29 May 2020 18:02
(name . Mayeul Cantan)(address . oss+guix@mayeul.net)(address . 41362@debbugs.gnu.org)
87o8q620gm.fsf@gnu.org
Hi,

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

Toggle quote (10 lines)
> 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:

Toggle snippet (40 lines)
[ 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; […]

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
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’.
L
L
Ludovic Courtès wrote on 29 May 2020 18:03
control message for bug #41362
(address . control@debbugs.gnu.org)
87mu5q20gb.fsf@gnu.org
severity 41362 important
quit
L
L
Ludovic Courtès wrote on 22 Jul 2020 22:28
Re: bug#41362: error when running guix pull on i686-linux
(name . Mayeul Cantan)(address . oss+guix@mayeul.net)(address . 41362@debbugs.gnu.org)
874kpzi9b2.fsf@gnu.org
Hi Mayeul,

Does this bug still show up for you?


TIA,
Ludo’.
M
M
Mayeul Cantan wrote on 23 Jul 2020 14:25
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 41362@debbugs.gnu.org)
98ab03d7-c172-03bb-481e-0021f3af30fe@cantan.eu
Toggle quote (5 lines)
> 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
L
L
Ludovic Courtès wrote on 24 Jul 2020 15:06
(name . Mayeul Cantan)(address . oss+guix@mayeul.net)(address . 41362@debbugs.gnu.org)
87a6zp9i55.fsf@gnu.org
Hello,

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

Toggle quote (16 lines)
> 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’.
L
L
Ludovic Courtès wrote on 11 Oct 2020 16:37
control message for bug #41362
(address . control@debbugs.gnu.org)
87d01og765.fsf@gnu.org
tags 41362 unreproducible
close 41362
quit
?
Your comment

This issue is archived.

To comment on this conversation send an email to 41362@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 41362
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch