[-- 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 --]
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’.
Hi Mayeul, Does this bug still show up for you? https://issues.guix.gnu.org/41362 TIA, Ludo’.
> 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
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’.