bug#32726: "make check" fails on master (0084744b)

bug#32726: "make check" fails on master (0084744b)

[Chris Marusich]

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

Hi Guix!

On commit 0084744b3af0a6f8e125120143f57567902339a8, "make check" fails
for me.  On an x86_64-linux GuixSD system, in a fresh Git worktree, I
ran the following commands.

First, create an environment for Guix:

  guix environment guix

In the environment, build Guix:

  ./bootstrap && ./configure --localstatedir=/var && make -j && make -j 1 check

I explicitly ran "make check" with "-j 1" because Guix's "check" target
is known to fail spuriously when run in parallel, as described
separately in bug 21097.

The tests still failed, even after I tried running "make -j 1 recheck",
which suggests that the failures are not spurious.

I skimmed the rather large "test-suite.log" file.  One possible problem
that jumped out at me was in the self-contained-tarball test, which
reads:

    test-name: self-contained-tarball
    location: /home/marusich/guix-fix-gnucash/tests/pack.scm:55
    [...]
    /home/marusich/guix-fix-gnucash/test-tmp/store/wkd9z38z99m8zg5dxk1jb316z8r1fj0v-bash-static-4.4.19/bin/bash ../../gcc-5.5.0/gcc/../move-if-c
    hange tmp-options.h options.h
    echo timestamp > s-options-h
    g++   -g -DIN_GCC    -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format 
    -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CO
    NFIG_H -DGENERATOR_FILE -Wl,-rpath=/home/marusich/guix-fix-gnucash/test-tmp/store/0fcqp8jy9lvp0cqdqjkrgh75npbnb2y8-glibc-2.27/lib -Wl,-dynam
    ic-linker -Wl,/home/marusich/guix-fix-gnucash/test-tmp/store/0fcqp8jy9lvp0cqdqjkrgh75npbnb2y8-glibc-2.27/lib/ld-linux-x86-64.so.2 -L/home/ma
    rusich/guix-fix-gnucash/test-tmp/store/b81y4n59lj7xf7cb9lhwz0lcdilzwxyz-libstdc++-5.5.0/lib -L/home/marusich/guix-fix-gnucash/test-tmp/store
    /x8p19sqgjmsp773glb2jf1mz9xigad3b-zlib-1.2.11/lib -Wl,-rpath=/home/marusich/guix-fix-gnucash/test-tmp/store/x8p19sqgjmsp773glb2jf1mz9xigad3b
    -zlib-1.2.11/lib -o build/genconstants \
        build/genconstants.o build/read-md.o build/errors.o ../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a
    x86_64-guix-linux-gnu-ld: cannot find -lstdc++
    collect2: error: ld returned 1 exit status
    make[3]: *** [Makefile:2615: build/genconstants] Error 1
    make[3]: *** Waiting for unfinished jobs....
    rm gcc.pod
    make[3]: Leaving directory '/tmp/guix-build-gcc-5.5.0.drv-0/build/gcc'
    make[2]: *** [Makefile:4378: all-stage1-gcc] Error 2
    make[2]: Leaving directory '/tmp/guix-build-gcc-5.5.0.drv-0/build'
    make[1]: *** [Makefile:21771: stage1-bubble] Error 2
    make[1]: Leaving directory '/tmp/guix-build-gcc-5.5.0.drv-0/build'
    make: *** [Makefile:909: all] Error 2

It looks like the test may have failed because GCC failed to build
because of the above ld-related problem.  Maybe we should look into why
GCC is failing.

The following tests also failed:

    test-name: program-file
    location: /home/marusich/guix-fix-gnucash/tests/gexp.scm:984

    test-name: program-file #:module-path
    location: /home/marusich/guix-fix-gnucash/tests/gexp.scm:1001

    test-name: program-file & with-extensions
    location: /home/marusich/guix-fix-gnucash/tests/gexp.scm:1029

They all failed with this similar looking output, although I'm not sure
if it's relevant to the actual test failures (yes, the output does seem
to be clobbered; I didn't paste this incorrectly):

    Unrecognized switch --no-auto-compiUsage: guile [OPTION]... [FILE]...
    Evaluate code with Guile, interactively or from a script.
    [... The rest of Guile's --help message follows ...]

I tried walking through the steps of the failing "program-file" test by
firing up a "./pre-inst-env guile" REPL and typing the forms in
manually.  It failed with a totally different message when I got to the
call to open-input-pipe:

    scheme@(guile-user)> (open-input-pipe "/gnu/store/hg281rkblxqgvrqi4viph1q3ghml7knm-program")
    $11 = #<input: #{read pipe}# 15>
    scheme@(guile-user)> Backtrace:
    In ice-9/eval.scm:
     432: 19 [eval # #]
    In ice-9/boot-9.scm:
    2320: 18 [save-module-excursion #<procedure 2b78c80 at ice-9/boot-9.scm:3961:3 ()>]
    3966: 17 [#<procedure 2b78c80 at ice-9/boot-9.scm:3961:3 ()>]
    1645: 16 [%start-stack load-stack ...]
    1650: 15 [#<procedure 2b7a300 ()>]
    In unknown file:
       ?: 14 [primitive-load "/gnu/store/hg281rkblxqgvrqi4viph1q3ghml7knm-program"]
    In ice-9/eval.scm:
     505: 13 [#<procedure 2a489a0 at ice-9/eval.scm:499:4 (exp)> (begin # #)]
    In ice-9/psyntax.scm:
    1091: 12 [expand-top-sequence ((begin # #)) () ((top)) ...]
     976: 11 [scan ((begin (use-modules #) (display 103706023244741))) () ...]
     976: 10 [scan ((use-modules (guix build utils)) (display 103706023244741)) () ...]
     270: 9 [scan ((# #) #(syntax-object *unspecified* # #)) () (()) ...]
    In ice-9/boot-9.scm:
    3513: 8 [process-use-modules (((guix build utils)))]
     627: 7 [map #<procedure 2af9520 at ice-9/boot-9.scm:3513:25 (mif-args)> ((#))]
    3514: 6 [#<procedure 2af9520 at ice-9/boot-9.scm:3513:25 (mif-args)> (#)]
    2783: 5 [resolve-interface (guix build utils) #:select ...]
    2708: 4 [#<procedure 2aefe00 at ice-9/boot-9.scm:2696:4 (name #:optional autoload version #:key ensure)> # ...]
    2981: 3 [try-module-autoload (guix build utils) #f]
    2320: 2 [save-module-excursion #<procedure 2b874e0 at ice-9/boot-9.scm:2982:17 ()>]
    3001: 1 [#<procedure 2b874e0 at ice-9/boot-9.scm:2982:17 ()>]
    In unknown file:
       ?: 0 [primitive-load-path "guix/build/utils" ...]

    ERROR: In procedure primitive-load-path:
    ERROR: In procedure make_objcode_from_file: bad header on object file: "\x7fELF\x02\x01\x01ÿ\x00\x00\x00\x00\x00\x00\x00\x00"

Sure enough, if I try to run the program directly from my shell, the
same error message ("bad header on object file") is displayed.  I don't
see how this relates to the test failure, though.  I'm surprised that
the "bad header on object file" error doesn't show up in the test suite
log; if this is the problem, I would have expected to see it in the test
suite logs.  Maybe it's a red herring.

And that's as far as I've gotten.  Can anyone reproduce this issue?

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

bug#32726: "make check" fails on master (0084744b)

[Gábor Boskovits]

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

Chris Marusich <cmmarusich@gmail.com> ezt írta (időpont: 2018. szept. 13.,
Cs, 6:49):

> Hi Guix!
>
> On commit 0084744b3af0a6f8e125120143f57567902339a8, "make check" fails
> for me.  On an x86_64-linux GuixSD system, in a fresh Git worktree, I
> ran the following commands.
>
> First, create an environment for Guix:
>
>   guix environment guix
>
> In the environment, build Guix:
>
>   ./bootstrap && ./configure --localstatedir=/var && make -j && make -j 1
> check
>
> I explicitly ran "make check" with "-j 1" because Guix's "check" target
> is known to fail spuriously when run in parallel, as described
> separately in bug 21097.
>
> The tests still failed, even after I tried running "make -j 1 recheck",
> which suggests that the failures are not spurious.
>
> I skimmed the rather large "test-suite.log" file.  One possible problem
> that jumped out at me was in the self-contained-tarball test, which
> reads:
>
>     test-name: self-contained-tarball
>     location: /home/marusich/guix-fix-gnucash/tests/pack.scm:55
>     [...]
>
> /home/marusich/guix-fix-gnucash/test-tmp/store/wkd9z38z99m8zg5dxk1jb316z8r1fj0v-bash-static-4.4.19/bin/bash
> ../../gcc-5.5.0/gcc/../move-if-c
>     hange tmp-options.h options.h
>     echo timestamp > s-options-h
>     g++   -g -DIN_GCC    -fno-exceptions -fno-rtti
> -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
> -Wcast-qual -Wno-format
>     -Wmissing-format-attribute -Woverloaded-virtual -pedantic
> -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common
> -DHAVE_CO
>     NFIG_H -DGENERATOR_FILE
> -Wl,-rpath=/home/marusich/guix-fix-gnucash/test-tmp/store/0fcqp8jy9lvp0cqdqjkrgh75npbnb2y8-glibc-2.27/lib
> -Wl,-dynam
>     ic-linker
> -Wl,/home/marusich/guix-fix-gnucash/test-tmp/store/0fcqp8jy9lvp0cqdqjkrgh75npbnb2y8-glibc-2.27/lib/ld-linux-x86-64.so.2
> -L/home/ma
>
> rusich/guix-fix-gnucash/test-tmp/store/b81y4n59lj7xf7cb9lhwz0lcdilzwxyz-libstdc++-5.5.0/lib
> -L/home/marusich/guix-fix-gnucash/test-tmp/store
>     /x8p19sqgjmsp773glb2jf1mz9xigad3b-zlib-1.2.11/lib
> -Wl,-rpath=/home/marusich/guix-fix-gnucash/test-tmp/store/x8p19sqgjmsp773glb2jf1mz9xigad3b
>     -zlib-1.2.11/lib -o build/genconstants \
>         build/genconstants.o build/read-md.o build/errors.o
> ../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a
>     x86_64-guix-linux-gnu-ld: cannot find -lstdc++
>     collect2: error: ld returned 1 exit status
>     make[3]: *** [Makefile:2615: build/genconstants] Error 1
>     make[3]: *** Waiting for unfinished jobs....
>     rm gcc.pod
>     make[3]: Leaving directory '/tmp/guix-build-gcc-5.5.0.drv-0/build/gcc'
>     make[2]: *** [Makefile:4378: all-stage1-gcc] Error 2
>     make[2]: Leaving directory '/tmp/guix-build-gcc-5.5.0.drv-0/build'
>     make[1]: *** [Makefile:21771: stage1-bubble] Error 2
>     make[1]: Leaving directory '/tmp/guix-build-gcc-5.5.0.drv-0/build'
>     make: *** [Makefile:909: all] Error 2
>
> It looks like the test may have failed because GCC failed to build
> because of the above ld-related problem.  Maybe we should look into why
> GCC is failing.
>
> The following tests also failed:
>
>     test-name: program-file
>     location: /home/marusich/guix-fix-gnucash/tests/gexp.scm:984
>
>     test-name: program-file #:module-path
>     location: /home/marusich/guix-fix-gnucash/tests/gexp.scm:1001
>
>     test-name: program-file & with-extensions
>     location: /home/marusich/guix-fix-gnucash/tests/gexp.scm:1029
>
> I can reproduce this, on commit: f309671c...


> They all failed with this similar looking output, although I'm not sure
> if it's relevant to the actual test failures (yes, the output does seem
> to be clobbered; I didn't paste this incorrectly):
>
>     Unrecognized switch --no-auto-compiUsage: guile [OPTION]... [FILE]...
>     Evaluate code with Guile, interactively or from a script.
>     [... The rest of Guile's --help message follows ...]
>
> I tried walking through the steps of the failing "program-file" test by
> firing up a "./pre-inst-env guile" REPL and typing the forms in
> manually.  It failed with a totally different message when I got to the
> call to open-input-pipe:
>
>     scheme@(guile-user)> (open-input-pipe
> "/gnu/store/hg281rkblxqgvrqi4viph1q3ghml7knm-program")
>     $11 = #<input: #{read pipe}# 15>
>     scheme@(guile-user)> Backtrace:
>     In ice-9/eval.scm:
>      432: 19 [eval # #]
>     In ice-9/boot-9.scm:
>     2320: 18 [save-module-excursion #<procedure 2b78c80 at
> ice-9/boot-9.scm:3961:3 ()>]
>     3966: 17 [#<procedure 2b78c80 at ice-9/boot-9.scm:3961:3 ()>]
>     1645: 16 [%start-stack load-stack ...]
>     1650: 15 [#<procedure 2b7a300 ()>]
>     In unknown file:
>        ?: 14 [primitive-load
> "/gnu/store/hg281rkblxqgvrqi4viph1q3ghml7knm-program"]
>     In ice-9/eval.scm:
>      505: 13 [#<procedure 2a489a0 at ice-9/eval.scm:499:4 (exp)> (begin #
> #)]
>     In ice-9/psyntax.scm:
>     1091: 12 [expand-top-sequence ((begin # #)) () ((top)) ...]
>      976: 11 [scan ((begin (use-modules #) (display 103706023244741))) ()
> ...]
>      976: 10 [scan ((use-modules (guix build utils)) (display
> 103706023244741)) () ...]
>      270: 9 [scan ((# #) #(syntax-object *unspecified* # #)) () (()) ...]
>     In ice-9/boot-9.scm:
>     3513: 8 [process-use-modules (((guix build utils)))]
>      627: 7 [map #<procedure 2af9520 at ice-9/boot-9.scm:3513:25
> (mif-args)> ((#))]
>     3514: 6 [#<procedure 2af9520 at ice-9/boot-9.scm:3513:25 (mif-args)>
> (#)]
>     2783: 5 [resolve-interface (guix build utils) #:select ...]
>     2708: 4 [#<procedure 2aefe00 at ice-9/boot-9.scm:2696:4 (name
> #:optional autoload version #:key ensure)> # ...]
>     2981: 3 [try-module-autoload (guix build utils) #f]
>     2320: 2 [save-module-excursion #<procedure 2b874e0 at
> ice-9/boot-9.scm:2982:17 ()>]
>     3001: 1 [#<procedure 2b874e0 at ice-9/boot-9.scm:2982:17 ()>]
>     In unknown file:
>        ?: 0 [primitive-load-path "guix/build/utils" ...]
>
>     ERROR: In procedure primitive-load-path:
>     ERROR: In procedure make_objcode_from_file: bad header on object file:
> "\x7fELF\x02\x01\x01ÿ\x00\x00\x00\x00\x00\x00\x00\x00"
>
> Sure enough, if I try to run the program directly from my shell, the
> same error message ("bad header on object file") is displayed.  I don't
> see how this relates to the test failure, though.  I'm surprised that
> the "bad header on object file" error doesn't show up in the test suite
> log; if this is the problem, I would have expected to see it in the test
> suite logs.  Maybe it's a red herring.
>
> And that's as far as I've gotten.  Can anyone reproduce this issue?
>
> --
> Chris
>

[-- Attachment #2: Type: text/html, Size: 7850 bytes --]

bug#32726: "make check" fails on master (0084744b)

[Chris Marusich]

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


As of commit d71078bc75d149c70dc573a259986f1731145693, this problem does
not occur for me.  "make check" passes.  I'm closing this bug report.

Note that d71078bc75d149c70dc573a259986f1731145693 is just a recent
commit I tested; it isn't the change that fixed the problem.

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

bug#32726: "make check" fails on master (0084744b)

[Ludovic Courtès]

Hi Chris,

Chris Marusich <cmmarusich@gmail.com> skribis:

> As of commit d71078bc75d149c70dc573a259986f1731145693, this problem does
> not occur for me.  "make check" passes.  I'm closing this bug report.
>
> Note that d71078bc75d149c70dc573a259986f1731145693 is just a recent
> commit I tested; it isn't the change that fixed the problem.

Heh OK, thanks for the heads-up anyway!

Ludo’.