Package: guix;
Reported by: Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de>
Date: Thu, 5 Feb 2015 13:58:01 UTC
Severity: normal
Done: ludo <at> gnu.org (Ludovic Courtès)
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 19780 in the body.
You can then email your comments to 19780 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
View this report as an mbox folder, status mbox, maintainer mbox
bug-guix <at> gnu.org:bug#19780; Package guix.
(Thu, 05 Feb 2015 13:58:02 GMT) Full text and rfc822 format available.Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de>:bug-guix <at> gnu.org.
(Thu, 05 Feb 2015 13:58:02 GMT) Full text and rfc822 format available.Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de> To: <bug-guix <at> gnu.org> Subject: 13 failing tests Date: Thu, 5 Feb 2015 14:55:03 +0100
[Message part 1 (text/plain, inline)]
When building Guix from master (currently that's commit 0ca0ce53a801702f6f56d68289675d4b448e026a) with make check I get the following output: ~~~~~~~~~~~~~~~~~~~~~~~ PASS: tests/base32.scm PASS: tests/base64.scm PASS: tests/hash.scm PASS: tests/pk-crypto.scm PASS: tests/pki.scm PASS: tests/sets.scm PASS: tests/substitute-binary.scm FAIL: tests/builders.scm FAIL: tests/derivations.scm PASS: tests/ui.scm PASS: tests/records.scm PASS: tests/utils.scm FAIL: tests/build-utils.scm FAIL: tests/packages.scm PASS: tests/snix.scm FAIL: tests/store.scm PASS: tests/monads.scm FAIL: tests/gexp.scm PASS: tests/nar.scm FAIL: tests/union.scm FAIL: tests/profiles.scm PASS: tests/syscalls.scm PASS: tests/lint.scm FAIL: tests/guix-build.sh PASS: tests/guix-download.sh PASS: tests/guix-hash.sh FAIL: tests/guix-package.sh PASS: tests/guix-system.sh FAIL: tests/guix-archive.sh PASS: tests/guix-authenticate.sh PASS: tests/guix-lint.sh FAIL: tests/guix-register.sh FAIL: tests/guix-gc.sh PASS: tests/guix-daemon.sh make[5]: Entering directory `/localhome/rwurmus-tmp/guix' make all-recursive make[6]: Entering directory `/localhome/rwurmus-tmp/guix' Making all in po/guix make[7]: Entering directory `/localhome/rwurmus-tmp/guix/po/guix' make[7]: Leaving directory `/localhome/rwurmus-tmp/guix/po/guix' Making all in po/packages make[7]: Entering directory `/localhome/rwurmus-tmp/guix/po/packages' make[7]: Leaving directory `/localhome/rwurmus-tmp/guix/po/packages' make[7]: Entering directory `/localhome/rwurmus-tmp/guix' make[7]: Leaving directory `/localhome/rwurmus-tmp/guix' make[6]: Leaving directory `/localhome/rwurmus-tmp/guix' make[5]: Leaving directory `/localhome/rwurmus-tmp/guix' ============================================================================ Testsuite summary for GNU Guix 0.8.1 ============================================================================ # TOTAL: 34 # PASS: 21 # SKIP: 0 # XFAIL: 0 # FAIL: 13 # XPASS: 0 # ERROR: 0 ============================================================================ See ./test-suite.log Please report to bug-guix <at> gnu.org ============================================================================ make[4]: *** [test-suite.log] Error 1 make[4]: Leaving directory `/localhome/rwurmus-tmp/guix' make[3]: *** [check-TESTS] Error 2 make[3]: Leaving directory `/localhome/rwurmus-tmp/guix' make[2]: *** [check-am] Error 2 make[2]: Leaving directory `/localhome/rwurmus-tmp/guix' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/localhome/rwurmus-tmp/guix' make: *** [check] Error 2 ~~~~~~~~~~~~~~~~~~~~~~~ Attached is a tarball containing the logs. ~~ Ricardo
[logs.tar (application/x-tar, attachment)]
bug-guix <at> gnu.org:bug#19780; Package guix.
(Sat, 07 Feb 2015 17:21:02 GMT) Full text and rfc822 format available.Message #8 received at 19780 <at> debbugs.gnu.org (full text, mbox):
From: ludo <at> gnu.org (Ludovic Courtès) To: Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de> Cc: 19780 <at> debbugs.gnu.org Subject: Re: bug#19780: 13 failing tests Date: Sat, 07 Feb 2015 18:19:53 +0100
What architecture is it?
There are a lot of these:
--8<---------------cut here---------------start------------->8---
builder for `/localhome/rwurmus-tmp/guix/test-tmp/store/m1cbz6gmyv2f5551j7zpm99d7mgy2zp9-guile-bootstrap-2.0.drv' failed due to signal 11 (Segmentation fault)
--8<---------------cut here---------------end--------------->8---
Could you run, from the top-level build tree, something like:
./test-env guix build --log-file \
/localhome/rwurmus-tmp/guix/test-tmp/store/m1cbz6gmyv2f5551j7zpm99d7mgy2zp9-guile-bootstrap-2.0.drv
and send the log file that it returns?
In addition, could you run:
cd gnu/packages/bootstrap/x86_64-linux # or whatever system that is
for i in bash mkdir tar xz ; do env -i ./$i --version || echo "FAIL -> $i" ; done
Is one of these programs failing?
TIA,
Ludo’.
bug-guix <at> gnu.org:bug#19780; Package guix.
(Tue, 10 Feb 2015 12:05:02 GMT) Full text and rfc822 format available.Message #11 received at 19780 <at> debbugs.gnu.org (full text, mbox):
From: Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de> To: Ludovic Courtès <ludo <at> gnu.org> Cc: 19780 <at> debbugs.gnu.org Subject: Re: bug#19780: 13 failing tests Date: Tue, 10 Feb 2015 13:03:45 +0100
Ludovic Courtès writes: > What architecture is it? It's x86_64-linux. ~~~~~~~ $ uname -a Linux guix-builder 3.10.0-123.20.1.el7.x86_64 #1 SMP Thu Jan 29 18:05:33 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux ~~~~~~~ > There are a lot of these: > > --8<---------------cut here---------------start------------->8--- > builder for `/localhome/rwurmus-tmp/guix/test-tmp/store/m1cbz6gmyv2f5551j7zpm99d7mgy2zp9-guile-bootstrap-2.0.drv' failed due to signal 11 (Segmentation fault) > --8<---------------cut here---------------end--------------->8--- > > Could you run, from the top-level build tree, something like: > > ./test-env guix build --log-file \ > /localhome/rwurmus-tmp/guix/test-tmp/store/m1cbz6gmyv2f5551j7zpm99d7mgy2zp9-guile-bootstrap-2.0.drv > > and send the log file that it returns? There isn't much output when I run this: ~~~~~~ [rwurmus <at> guix-builder:/localhome/rwurmus-tmp/guix] (677) $ ./test-env guix build --log-file \ > /localhome/rwurmus-tmp/guix/test-tmp/store/m1cbz6gmyv2f5551j7zpm99d7mgy2zp9-guile-bootstrap-2.0.drv accepted connection from pid 4764, uid 22840 /localhome/rwurmus-tmp/guix/test-tmp/var/log/guix/drvs/m1/cbz6gmyv2f5551j7zpm99d7mgy2zp9-guile-bootstrap-2.0.drv.bz2 1 operations ./test-env: line 1: 4763 Terminated "/localhome/rwurmus-tmp/guix/pre-inst-env" "/localhome/rwurmus-tmp/guix/guix-daemon" --disable-chroot --substitute-urls="$GUIX_BINARY_SUBSTITUTE_URL" [rwurmus <at> guix-builder:/localhome/rwurmus-tmp/guix] (678) $ ~~~~~~ Running `bzcat cbz6gmyv2f5551j7zpm99d7mgy2zp9-guile-bootstrap-2.0.drv.bz2` yields nothing. The log appears to be empty. > In addition, could you run: > > cd gnu/packages/bootstrap/x86_64-linux # or whatever system that is > for i in bash mkdir tar xz ; do env -i ./$i --version || echo "FAIL -> $i" ; done > > Is one of these programs failing? ~~~~~~ [rwurmus <at> guix-builder:/localhome/rwurmus-tmp/guix] (688) $ cd gnu/packages/bootstrap/x86_64-linux [rwurmus <at> guix-builder:/localhome/rwurmus-tmp/guix/gnu/packages/bootstrap/x86_64-linux] (689) $ for i in bash mkdir tar xz ; do env -i ./$i --version || echo "FAIL -> $i" ; done GNU bash, version 4.2.0(2)-release (x86_64-unknown-linux-gnu) Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software; you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. mkdir (GNU coreutils) 8.19 Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by David MacKenzie. tar (GNU tar) 1.26 Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by John Gilmore and Jay Fenlason. xz (XZ Utils) 5.0.4 liblzma 5.0.4 [rwurmus <at> guix-builder:/localhome/rwurmus-tmp/guix/gnu/packages/bootstrap/x86_64-linux] (690) $ ~~~~~~ This looks all right to me. ~~ Ricardo
bug-guix <at> gnu.org:bug#19780; Package guix.
(Tue, 10 Feb 2015 12:43:02 GMT) Full text and rfc822 format available.Message #14 received at 19780 <at> debbugs.gnu.org (full text, mbox):
From: ludo <at> gnu.org (Ludovic Courtès) To: Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de> Cc: 19780 <at> debbugs.gnu.org Subject: Re: bug#19780: 13 failing tests Date: Tue, 10 Feb 2015 13:42:18 +0100
Hmm. Could you try: ./test-env guix build guile-bootstrap and ./pre-inst-env guix build guile-bootstrap --no-substitutes ? Thanks, Ludo’.
bug-guix <at> gnu.org:bug#19780; Package guix.
(Tue, 10 Feb 2015 14:16:02 GMT) Full text and rfc822 format available.Message #17 received at 19780 <at> debbugs.gnu.org (full text, mbox):
From: Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de> To: Ludovic Courtès <ludo <at> gnu.org> Cc: 19780 <at> debbugs.gnu.org Subject: Re: bug#19780: 13 failing tests Date: Tue, 10 Feb 2015 15:15:30 +0100
Ludovic Courtès writes: > Hmm. Could you try: > > ./test-env guix build guile-bootstrap ~~~~~~~~~~~~~~ [rwurmus <at> guix-builder:/localhome/rwurmus-tmp/guix] (720) $ ./test-env guix build guile-bootstrap accepted connection from pid 2187, uid 22840 substitute-binary: warning: authentication and authorization of substitutes disabled! substitute-binary: guix substitute-binary: warning: ACL for archive imports seems to be uninitialized, substitutes may be unavailable substitute-binary: updating list of substitutes from 'file:///localhome/rwurmus-tmp/guix/test-tmp/var/2181/substituter-data'... The following derivation will be built: /localhome/rwurmus-tmp/guix/test-tmp/store/m1cbz6gmyv2f5551j7zpm99d7mgy2zp9-guile-bootstrap-2.0.drv @ build-started /localhome/rwurmus-tmp/guix/test-tmp/store/m1cbz6gmyv2f5551j7zpm99d7mgy2zp9-guile-bootstrap-2.0.drv - x86_64-linux /localhome/rwurmus-tmp/guix/test-tmp/var/log/guix/drvs/m1//cbz6gmyv2f5551j7zpm99d7mgy2zp9-guile-bootstrap-2.0.drv.bz2 builder for `/localhome/rwurmus-tmp/guix/test-tmp/store/m1cbz6gmyv2f5551j7zpm99d7mgy2zp9-guile-bootstrap-2.0.drv' failed due to signal 11 (Segmentation fault) @ build-failed /localhome/rwurmus-tmp/guix/test-tmp/store/m1cbz6gmyv2f5551j7zpm99d7mgy2zp9-guile-bootstrap-2.0.drv - 1 builder for `/localhome/rwurmus-tmp/guix/test-tmp/store/m1cbz6gmyv2f5551j7zpm99d7mgy2zp9-guile-bootstrap-2.0.drv' failed due to signal 11 (Segmentation fault) killing process 2236 guix build: error: build failed: build of `/localhome/rwurmus-tmp/guix/test-tmp/store/m1cbz6gmyv2f5551j7zpm99d7mgy2zp9-guile-bootstrap-2.0.drv' failed 13 operations ./test-env: line 1: 2186 Terminated "/localhome/rwurmus-tmp/guix/pre-inst-env" "/localhome/rwurmus-tmp/guix/guix-daemon" --disable-chroot --substitute-urls="$GUIX_BINARY_SUBSTITUTE_URL" [rwurmus <at> guix-builder:/localhome/rwurmus-tmp/guix] (721) $ ~~~~~~~~~~~~~~ > and > > ./pre-inst-env guix build guile-bootstrap --no-substitutes I'm running the guix-daemon in debug mode: ~~~~~~~~~~~~~~ [rwurmus <at> guix-builder:/localhome/rwurmus-tmp/guix] (722) $ ./pre-inst-env guix build guile-bootstrap --no-substitutes acquiring global GC lock `/var/guix/gc.lock' acquiring read lock on `/var/guix/temproots/3004' acquiring write lock on `/var/guix/temproots/3004' downgrading to read lock on `/var/guix/temproots/3004' acquiring write lock on `/var/guix/temproots/3004' downgrading to read lock on `/var/guix/temproots/3004' acquiring write lock on `/var/guix/temproots/3004' downgrading to read lock on `/var/guix/temproots/3004' acquiring write lock on `/var/guix/temproots/3004' downgrading to read lock on `/var/guix/temproots/3004' acquiring write lock on `/var/guix/temproots/3004' downgrading to read lock on `/var/guix/temproots/3004' acquiring write lock on `/var/guix/temproots/3004' downgrading to read lock on `/var/guix/temproots/3004' acquiring write lock on `/var/guix/temproots/3004' downgrading to read lock on `/var/guix/temproots/3004' The following derivation will be built: /gnu/store/vbcm1mibrsc2j4fnyhskdbwzshs07fs6-guile-bootstrap-2.0.drv @ build-started /gnu/store/vbcm1mibrsc2j4fnyhskdbwzshs07fs6-guile-bootstrap-2.0.drv - x86_64-linux /var/log/guix/drvs/vb//cm1mibrsc2j4fnyhskdbwzshs07fs6-guile-bootstrap-2.0.drv.bz2 unpacking bootstrap Guile to '/gnu/store/c5cs53y3j5vkvvshxn9x0ms9dgjm5vhf-guile-bootstrap-2.0'... ./ ./share/ ./share/guile/ ./share/guile/2.0/ ./share/guile/2.0/system/ ./share/guile/2.0/system/xref.scm ./share/guile/2.0/system/foreign.scm [...] ./lib/guile/2.0/ccache/srfi/srfi-10.go ./lib/guile/2.0/ccache/srfi/srfi-35.go ./lib/guile/2.0/ccache/srfi/srfi-98.go ./lib/guile/2.0/ccache/texinfo.go ./lib/guile/2.0/ccache/statprof.go ./bin/ ./bin/guile guile (GNU Guile) 2.0.9 Copyright (C) 2013 Free Software Foundation, Inc. License LGPLv3+: GNU LGPL 3 or later <http://gnu.org/licenses/lgpl.html>. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. @ build-succeeded /gnu/store/vbcm1mibrsc2j4fnyhskdbwzshs07fs6-guile-bootstrap-2.0.drv - /gnu/store/c5cs53y3j5vkvvshxn9x0ms9dgjm5vhf-guile-bootstrap-2.0 ~~~~~~~~~~~~~~ ~~ Ricardo
bug-guix <at> gnu.org:bug#19780; Package guix.
(Tue, 10 Feb 2015 14:32:03 GMT) Full text and rfc822 format available.Message #20 received at 19780 <at> debbugs.gnu.org (full text, mbox):
From: ludo <at> gnu.org (Ludovic Courtès) To: Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de> Cc: 19780 <at> debbugs.gnu.org Subject: Re: bug#19780: 13 failing tests Date: Tue, 10 Feb 2015 15:30:58 +0100
So building guile-bootstrap in the real store works, but fails in the test store. Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de> skribis: > [rwurmus <at> guix-builder:/localhome/rwurmus-tmp/guix] (720) $ ./test-env guix build guile-bootstrap [...] > @ build-started /localhome/rwurmus-tmp/guix/test-tmp/store/m1cbz6gmyv2f5551j7zpm99d7mgy2zp9-guile-bootstrap-2.0.drv - x86_64-linux /localhome/rwurmus-tmp/guix/test-tmp/var/log/guix/drvs/m1//cbz6gmyv2f5551j7zpm99d7mgy2zp9-guile-bootstrap-2.0.drv.bz2 > builder for `/localhome/rwurmus-tmp/guix/test-tmp/store/m1cbz6gmyv2f5551j7zpm99d7mgy2zp9-guile-bootstrap-2.0.drv' failed due to signal 11 (Segmentation fault) Could you “rm -rf /localhome/rwurmus-tmp/guix/test-tmp” and try again? If that fails again, could you run ‘ulimit -c unlimited’ before running the command, add see if we get a core dump from which to extract that Bash backtrace? TIA, Ludo’.
bug-guix <at> gnu.org:bug#19780; Package guix.
(Tue, 10 Feb 2015 15:00:05 GMT) Full text and rfc822 format available.Message #23 received at 19780 <at> debbugs.gnu.org (full text, mbox):
From: Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de> To: Ludovic Courtès <ludo <at> gnu.org> Cc: 19780 <at> debbugs.gnu.org Subject: Re: bug#19780: 13 failing tests Date: Tue, 10 Feb 2015 15:59:01 +0100
Ludovic Courtès writes: >> [rwurmus <at> guix-builder:/localhome/rwurmus-tmp/guix] (720) $ ./test-env guix build guile-bootstrap > > [...] > >> @ build-started /localhome/rwurmus-tmp/guix/test-tmp/store/m1cbz6gmyv2f5551j7zpm99d7mgy2zp9-guile-bootstrap-2.0.drv - x86_64-linux /localhome/rwurmus-tmp/guix/test-tmp/var/log/guix/drvs/m1//cbz6gmyv2f5551j7zpm99d7mgy2zp9-guile-bootstrap-2.0.drv.bz2 >> builder for `/localhome/rwurmus-tmp/guix/test-tmp/store/m1cbz6gmyv2f5551j7zpm99d7mgy2zp9-guile-bootstrap-2.0.drv' failed due to signal 11 (Segmentation fault) > > Could you “rm -rf /localhome/rwurmus-tmp/guix/test-tmp” and try again? Same after rm-rf'ing. > If that fails again, could you run ‘ulimit -c unlimited’ before running > the command, add see if we get a core dump from which to extract that > Bash backtrace? Oddly, I cannot seem to get a core dump, even after setting ulimit -c unlimited. Is there a way to run the failing builder manually?
bug-guix <at> gnu.org:bug#19780; Package guix.
(Tue, 10 Feb 2015 15:51:02 GMT) Full text and rfc822 format available.Message #26 received at 19780 <at> debbugs.gnu.org (full text, mbox):
From: ludo <at> gnu.org (Ludovic Courtès) To: Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de> Cc: 19780 <at> debbugs.gnu.org Subject: Re: bug#19780: 13 failing tests Date: Tue, 10 Feb 2015 16:49:56 +0100
[Message part 1 (text/plain, inline)]
Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de> skribis: > Oddly, I cannot seem to get a core dump, even after setting ulimit -c > unlimited. Is there a way to run the failing builder manually? No. Could you try something like this:
[Message part 2 (text/x-patch, inline)]
diff --git a/test-env.in b/test-env.in
index f66a0db..9cdd479 100644
--- a/test-env.in
+++ b/test-env.in
@@ -90,7 +90,8 @@ then
--substitute-urls="$GUIX_BINARY_SUBSTITUTE_URL" &
daemon_pid=$!
- trap "kill $daemon_pid ; rm -rf $NIX_STATE_DIR" EXIT
+ echo "please attach gdb to $daemon_pid and hit enter"
+ read
fi
# Avoid issues that could stem from l10n, such as language/encoding
[Message part 3 (text/plain, inline)]
When you see the message, run this from another terminal: $ gdb (gdb) attach 1234 (gdb) set detach-on-fork off (gdb) continue Normally GDB will stop when the child process receives SIGSEGV. At that point, you should be able to type “bt” to get the backtrace. Could you try that? Thanks in advance, Ludo’.
bug-guix <at> gnu.org:bug#19780; Package guix.
(Tue, 10 Feb 2015 16:46:02 GMT) Full text and rfc822 format available.Message #29 received at 19780 <at> debbugs.gnu.org (full text, mbox):
From: Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de> To: Ludovic Courtès <ludo <at> gnu.org> Cc: 19780 <at> debbugs.gnu.org Subject: Re: bug#19780: 13 failing tests Date: Tue, 10 Feb 2015 17:45:24 +0100
Ludovic Courtès writes: > When you see the message, run this from another terminal: > > $ gdb > (gdb) attach 1234 > (gdb) set detach-on-fork off > (gdb) continue > > Normally GDB will stop when the child process receives SIGSEGV. At that > point, you should be able to type “bt” to get the backtrace. I applied the patch and did as instructed, but even after half an hour there is no more progress. I'll leave this running over night, hoping for a segfault when I return to it the next morning. Here's the output so far: ~~~~~~~ [rwurmus <at> guix-builder:~] (506) $ gdb GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-51.el7 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. (gdb) attach 26379 Attaching to process 26379 Reading symbols from /localhome/rwurmus-tmp/guix/guix-daemon...done. Reading symbols from /lib64/libbz2.so.1...Reading symbols from /lib64/libbz2.so.1...(no debugging symbols found)...done. (no debugging symbols found)...done. Loaded symbols for /lib64/libbz2.so.1 Reading symbols from /lib64/libsqlite3.so.0...Reading symbols from /lib64/libsqlite3.so.0...(no debugging symbols found)...done. (no debugging symbols found)...done. Loaded symbols for /lib64/libsqlite3.so.0 Reading symbols from /lib64/libgcrypt.so.11...Reading symbols from /lib64/libgcrypt.so.11...(no debugging symbols found)...done. (no debugging symbols found)...done. Loaded symbols for /lib64/libgcrypt.so.11 Reading symbols from /lib64/libstdc++.so.6...(no debugging symbols found)...done. Loaded symbols for /lib64/libstdc++.so.6 Reading symbols from /lib64/libm.so.6...(no debugging symbols found)...done. Loaded symbols for /lib64/libm.so.6 Reading symbols from /lib64/libgcc_s.so.1...(no debugging symbols found)...done. Loaded symbols for /lib64/libgcc_s.so.1 Reading symbols from /lib64/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib64/libc.so.6 Reading symbols from /lib64/libpthread.so.0...(no debugging symbols found)...done. [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Loaded symbols for /lib64/libpthread.so.0 Reading symbols from /lib64/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libdl.so.2 Reading symbols from /lib64/libgpg-error.so.0...Reading symbols from /lib64/libgpg-error.so.0...(no debugging symbols found)...done. (no debugging symbols found)...done. Loaded symbols for /lib64/libgpg-error.so.0 Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/ld-linux-x86-64.so.2 0x00007f0074bc9e40 in __accept_nocancel () from /lib64/libc.so.6 Missing separate debuginfos, use: debuginfo-install bzip2-libs-1.0.6-12.el7.x86_64 glibc-2.17-55.el7_0.5.x86_64 libgcc-4.8.2-16.2.el7_0.x86_64 libgcrypt-1.5.3-4.el7.x86_64 libgpg-error-1.12-3.el7.x86_64 libstdc++-4.8.2-16.2.el7_0.x86_64 sqlite-3.7.17-4.el7.x86_64 (gdb) set detach-on-fork off (gdb) continue Continuing. [New process 26393] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". ~~~~~~~ The process itself outputs nothing of interest: ~~~~~~~ [rwurmus <at> guix-builder:/localhome/rwurmus-tmp/guix] (697) $ ./test-env guix build guile-bootstrap please attach gdb to 26379 and hit enter accepted connection from pid 26389, uid 22840 ~~~~~~~ ~~ Ricardo
bug-guix <at> gnu.org:bug#19780; Package guix.
(Tue, 10 Feb 2015 17:09:01 GMT) Full text and rfc822 format available.Message #32 received at 19780 <at> debbugs.gnu.org (full text, mbox):
From: ludo <at> gnu.org (Ludovic Courtès) To: Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de> Cc: 19780 <at> debbugs.gnu.org Subject: Re: bug#19780: 13 failing tests Date: Tue, 10 Feb 2015 18:08:33 +0100
Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de> skribis: > I applied the patch and did as instructed, but even after half an hour > there is no more progress. I'll leave this running over night, hoping > for a segfault when I return to it the next morning. Hmm could you restore the ‘trap’ line in ‘test-env’? That’s probably the reason why it doesn’t complete. Still, that means that the SIGSEGV doesn’t show up when running under GDB. :-/ Alternately, could you change ‘test-env’ so that guix-daemon runs under Valgrind? TIA, Ludo’.
bug-guix <at> gnu.org:bug#19780; Package guix.
(Wed, 11 Feb 2015 11:08:02 GMT) Full text and rfc822 format available.Message #35 received at 19780 <at> debbugs.gnu.org (full text, mbox):
From: Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de> To: Ludovic Courtès <ludo <at> gnu.org> Cc: 19780 <at> debbugs.gnu.org Subject: Re: bug#19780: 13 failing tests Date: Wed, 11 Feb 2015 12:06:58 +0100
[Message part 1 (text/plain, inline)]
Ludovic Courtès writes:
> Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de> skribis:
>
>> I applied the patch and did as instructed, but even after half an hour
>> there is no more progress. I'll leave this running over night, hoping
>> for a segfault when I return to it the next morning.
>
> Hmm could you restore the ‘trap’ line in ‘test-env’? That’s probably
> the reason why it doesn’t complete.
I restored the trap line, but as long as GDB is attached there's no
progress. When I do not "set detach-on-fork off" I observe the
segfault, and I also see it when I disconnect GDB.
> Still, that means that the SIGSEGV doesn’t show up when running under
> GDB. :-/
>
> Alternately, could you change ‘test-env’ so that guix-daemon runs under
> Valgrind?
(NOTE: I'm not a very experienced user of debuggers; I'm only familiar
with the basics as my needs haven't been very demanding in the past.)
I tried to run the daemon under valgrind. Instead of modifying test-env
like this:
"/localhome/rwurmus-tmp/guix/pre-inst-env" \
valgrind --trace-children=yes \
"/localhome/rwurmus-tmp/guix/guix-daemon" --disable-chroot \
--substitute-urls="$GUIX_BINARY_SUBSTITUTE_URL" &
I injected valgrind in the exec line of pre-inst-env, like this:
exec valgrind --trace-children=yes "$@"
Modifying test-env only gave me errors about the socket file not being
found, so I did not spend much more time investigating it. With the
modified pre-inst-env, however, valgrind produced a very long log, which
I attached below. The interesting part is probably this section near
the end:
~~~~~~~~~~~~~~~~~~~~~~~
==9202== Jump to the invalid address stated on the next line
==9202== at 0x0: ???
==9202== by 0x5308B23: __pthread_initialize_minimal (nptl-init.c:467)
==9202== by 0x5307408: ??? (in /usr/lib64/libpthread-2.17.so)
==9202== by 0x50F9F5F: ??? (in /usr/lib64/libnss_sss.so.2)
==9202== by 0x4F56F1: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash)
==9202== by 0x4F5836: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash)
==9202== by 0x4DBB59: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash)
==9202== by 0x4D9E65: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash)
==9202== by 0x4DB476: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash)
==9202== by 0x4DDA86: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash)
==9202== by 0x4D9E65: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash)
==9202== by 0x4DD8D6: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash)
==9202== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==9202==
==9202==
==9202== Process terminating with default action of signal 11 (SIGSEGV)
==9202== Bad permissions for mapped region at address 0x0
==9202== at 0x0: ???
==9202== by 0x5308B23: __pthread_initialize_minimal (nptl-init.c:467)
==9202== by 0x5307408: ??? (in /usr/lib64/libpthread-2.17.so)
==9202== by 0x50F9F5F: ??? (in /usr/lib64/libnss_sss.so.2)
==9202== by 0x4F56F1: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash)
==9202== by 0x4F5836: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash)
==9202== by 0x4DBB59: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash)
==9202== by 0x4D9E65: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash)
==9202== by 0x4DB476: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash)
==9202== by 0x4DDA86: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash)
==9202== by 0x4D9E65: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash)
==9202== by 0x4DD8D6: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash)
~~~~~~~~~~~~~~~~~~~~~~~
libnss_sss is used because on my workstation we use sssd for user
authentication with LDAP. On a possibly related note, Emacs installed
through Guix on this Fedora 21 workstation fails to find my user's home
directory (which is mounted over NFS). Upon starting Emacs I get this
error: "Error (initialization): User rwurmus has no home directory";
"--debug-init" does not make any difference. HOME is set, of course. I
wonder if this is a helpful clue.
~~ Ricardo
[valgrind.log (text/plain, attachment)]
bug-guix <at> gnu.org:bug#19780; Package guix.
(Wed, 11 Feb 2015 11:26:02 GMT) Full text and rfc822 format available.bug-guix <at> gnu.org:bug#19780; Package guix.
(Wed, 11 Feb 2015 11:41:02 GMT) Full text and rfc822 format available.Message #41 received at 19780 <at> debbugs.gnu.org (full text, mbox):
From: Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de> To: Ludovic Courtès <ludo <at> gnu.org> Cc: 19780 <at> debbugs.gnu.org Subject: Re: bug#19780: 13 failing tests Date: Wed, 11 Feb 2015 12:39:39 +0100
[Message part 1 (text/plain, inline)]
Ludovic Courtès writes:
> Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de> skribis:
>
>> I applied the patch and did as instructed, but even after half an hour
>> there is no more progress. I'll leave this running over night, hoping
>> for a segfault when I return to it the next morning.
>
> Hmm could you restore the ‘trap’ line in ‘test-env’? That’s probably
> the reason why it doesn’t complete.
I restored the trap line, but as long as GDB is attached there's no
progress. When I do not "set detach-on-fork off" I observe the
segfault, and I also see it when I disconnect GDB.
> Still, that means that the SIGSEGV doesn’t show up when running under
> GDB. :-/
>
> Alternately, could you change ‘test-env’ so that guix-daemon runs under
> Valgrind?
(NOTE: I'm not a very experienced user of debuggers; I'm only familiar
with the basics as my needs haven't been very demanding in the past.)
I tried to run the daemon under valgrind. Instead of modifying test-env
like this:
"/localhome/rwurmus-tmp/guix/pre-inst-env" \
valgrind --trace-children=yes \
"/localhome/rwurmus-tmp/guix/guix-daemon" --disable-chroot \
--substitute-urls="$GUIX_BINARY_SUBSTITUTE_URL" &
I injected valgrind in the exec line of pre-inst-env, like this:
exec valgrind --trace-children=yes "$@"
Modifying test-env only gave me errors about the socket file not being
found, so I did not spend much more time investigating it. With the
modified pre-inst-env, however, valgrind produced a very long log, which
I attached below. The interesting part is probably this section near
the end:
~~~~~~~~~~~~~~~~~~~~~~~
==9202== Jump to the invalid address stated on the next line
==9202== at 0x0: ???
==9202== by 0x5308B23: __pthread_initialize_minimal (nptl-init.c:467)
==9202== by 0x5307408: ??? (in /usr/lib64/libpthread-2.17.so)
==9202== by 0x50F9F5F: ??? (in /usr/lib64/libnss_sss.so.2)
==9202== by 0x4F56F1: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash)
==9202== by 0x4F5836: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash)
==9202== by 0x4DBB59: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash)
==9202== by 0x4D9E65: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash)
==9202== by 0x4DB476: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash)
==9202== by 0x4DDA86: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash)
==9202== by 0x4D9E65: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash)
==9202== by 0x4DD8D6: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash)
==9202== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==9202==
==9202==
==9202== Process terminating with default action of signal 11 (SIGSEGV)
==9202== Bad permissions for mapped region at address 0x0
==9202== at 0x0: ???
==9202== by 0x5308B23: __pthread_initialize_minimal (nptl-init.c:467)
==9202== by 0x5307408: ??? (in /usr/lib64/libpthread-2.17.so)
==9202== by 0x50F9F5F: ??? (in /usr/lib64/libnss_sss.so.2)
==9202== by 0x4F56F1: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash)
==9202== by 0x4F5836: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash)
==9202== by 0x4DBB59: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash)
==9202== by 0x4D9E65: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash)
==9202== by 0x4DB476: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash)
==9202== by 0x4DDA86: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash)
==9202== by 0x4D9E65: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash)
==9202== by 0x4DD8D6: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash)
~~~~~~~~~~~~~~~~~~~~~~~
libnss_sss is used because on my workstation we use sssd for user
authentication with LDAP. On a possibly related note, Emacs installed
through Guix on this Fedora 21 workstation fails to find my user's home
directory (which is mounted over NFS). Upon starting Emacs I get this
error: "Error (initialization): User rwurmus has no home directory";
"--debug-init" does not make any difference. HOME is set, of course. I
wonder if this is a helpful clue.
~~ Ricardo
[valgrind.log (text/plain, attachment)]
bug-guix <at> gnu.org:bug#19780; Package guix.
(Wed, 11 Feb 2015 11:49:02 GMT) Full text and rfc822 format available.bug-guix <at> gnu.org:bug#19780; Package guix.
(Wed, 11 Feb 2015 12:40:02 GMT) Full text and rfc822 format available.bug-guix <at> gnu.org:bug#19780; Package guix.
(Wed, 11 Feb 2015 12:42:02 GMT) Full text and rfc822 format available.Message #50 received at 19780 <at> debbugs.gnu.org (full text, mbox):
From: Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de> To: Ludovic Courtès <ludo <at> gnu.org> Cc: 19780 <at> debbugs.gnu.org Subject: Re: bug#19780: 13 failing tests Date: Wed, 11 Feb 2015 13:40:47 +0100
[Message part 1 (text/plain, inline)]
Ludovic Courtès writes:
> Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de> skribis:
>
>> I applied the patch and did as instructed, but even after half an hour
>> there is no more progress. I'll leave this running over night, hoping
>> for a segfault when I return to it the next morning.
>
> Hmm could you restore the ‘trap’ line in ‘test-env’? That’s probably
> the reason why it doesn’t complete.
I restored the trap line, but as long as GDB is attached there's no
progress. When I do not "set detach-on-fork off" I observe the
segfault, and I also see it when I disconnect GDB.
> Still, that means that the SIGSEGV doesn’t show up when running under
> GDB. :-/
>
> Alternately, could you change ‘test-env’ so that guix-daemon runs under
> Valgrind?
(NOTE: I'm not a very experienced user of debuggers; I'm only familiar
with the basics as my needs haven't been very demanding in the past.)
I tried to run the daemon under valgrind. Instead of modifying test-env
like this:
"/localhome/rwurmus-tmp/guix/pre-inst-env" \
valgrind --trace-children=yes \
"/localhome/rwurmus-tmp/guix/guix-daemon" --disable-chroot \
--substitute-urls="$GUIX_BINARY_SUBSTITUTE_URL" &
I injected valgrind in the exec line of pre-inst-env, like this:
exec valgrind --trace-children=yes "$@"
Modifying test-env only gave me errors about the socket file not being
found, so I did not spend much more time investigating it. With the
modified pre-inst-env, however, valgrind produced a very long log, which
I attached below. The interesting part is probably this section near
the end:
~~~~~~~~~~~~~~~~~~~~~~~
==9202== Jump to the invalid address stated on the next line
==9202== at 0x0: ???
==9202== by 0x5308B23: __pthread_initialize_minimal (nptl-init.c:467)
==9202== by 0x5307408: ??? (in /usr/lib64/libpthread-2.17.so)
==9202== by 0x50F9F5F: ??? (in /usr/lib64/libnss_sss.so.2)
==9202== by 0x4F56F1: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash)
==9202== by 0x4F5836: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash)
==9202== by 0x4DBB59: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash)
==9202== by 0x4D9E65: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash)
==9202== by 0x4DB476: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash)
==9202== by 0x4DDA86: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash)
==9202== by 0x4D9E65: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash)
==9202== by 0x4DD8D6: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash)
==9202== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==9202==
==9202==
==9202== Process terminating with default action of signal 11 (SIGSEGV)
==9202== Bad permissions for mapped region at address 0x0
==9202== at 0x0: ???
==9202== by 0x5308B23: __pthread_initialize_minimal (nptl-init.c:467)
==9202== by 0x5307408: ??? (in /usr/lib64/libpthread-2.17.so)
==9202== by 0x50F9F5F: ??? (in /usr/lib64/libnss_sss.so.2)
==9202== by 0x4F56F1: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash)
==9202== by 0x4F5836: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash)
==9202== by 0x4DBB59: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash)
==9202== by 0x4D9E65: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash)
==9202== by 0x4DB476: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash)
==9202== by 0x4DDA86: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash)
==9202== by 0x4D9E65: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash)
==9202== by 0x4DD8D6: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash)
~~~~~~~~~~~~~~~~~~~~~~~
libnss_sss is used because on my workstation we use sssd for user
authentication with LDAP. On a possibly related note, Emacs installed
through Guix on this Fedora 21 workstation fails to find my user's home
directory (which is mounted over NFS). Upon starting Emacs I get this
error: "Error (initialization): User rwurmus has no home directory";
"--debug-init" does not make any difference. HOME is set, of course. I
wonder if this is a helpful clue.
~~ Ricardo
[valgrind.log (text/plain, attachment)]
bug-guix <at> gnu.org:bug#19780; Package guix.
(Wed, 11 Feb 2015 12:43:01 GMT) Full text and rfc822 format available.bug-guix <at> gnu.org:bug#19780; Package guix.
(Wed, 11 Feb 2015 13:01:02 GMT) Full text and rfc822 format available.bug-guix <at> gnu.org:bug#19780; Package guix.
(Wed, 11 Feb 2015 13:24:02 GMT) Full text and rfc822 format available.bug-guix <at> gnu.org:bug#19780; Package guix.
(Wed, 11 Feb 2015 13:50:02 GMT) Full text and rfc822 format available.bug-guix <at> gnu.org:bug#19780; Package guix.
(Wed, 11 Feb 2015 13:51:02 GMT) Full text and rfc822 format available.bug-guix <at> gnu.org:bug#19780; Package guix.
(Wed, 11 Feb 2015 13:53:01 GMT) Full text and rfc822 format available.bug-guix <at> gnu.org:bug#19780; Package guix.
(Fri, 13 Feb 2015 09:15:01 GMT) Full text and rfc822 format available.Message #71 received at 19780 <at> debbugs.gnu.org (full text, mbox):
From: ludo <at> gnu.org (Ludovic Courtès) To: Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de> Cc: 19780 <at> debbugs.gnu.org Subject: Re: bug#19780: 13 failing tests Date: Fri, 13 Feb 2015 10:14:24 +0100
Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de> skribis: > Modifying test-env only gave me errors about the socket file not being > found, so I did not spend much more time investigating it. With the > modified pre-inst-env, however, valgrind produced a very long log, which > I attached below. The interesting part is probably this section near > the end: > > ~~~~~~~~~~~~~~~~~~~~~~~ > ==9202== Jump to the invalid address stated on the next line > ==9202== at 0x0: ??? > ==9202== by 0x5308B23: __pthread_initialize_minimal (nptl-init.c:467) > ==9202== by 0x5307408: ??? (in /usr/lib64/libpthread-2.17.so) > ==9202== by 0x50F9F5F: ??? (in /usr/lib64/libnss_sss.so.2) > ==9202== by 0x4F56F1: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash) > ==9202== by 0x4F5836: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash) > ==9202== by 0x4DBB59: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash) > ==9202== by 0x4D9E65: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash) > ==9202== by 0x4DB476: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash) > ==9202== by 0x4DDA86: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash) > ==9202== by 0x4D9E65: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash) > ==9202== by 0x4DD8D6: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash) > ==9202== Address 0x0 is not stack'd, malloc'd or (recently) free'd > ==9202== > ==9202== > ==9202== Process terminating with default action of signal 11 (SIGSEGV) > ==9202== Bad permissions for mapped region at address 0x0 > ==9202== at 0x0: ??? > ==9202== by 0x5308B23: __pthread_initialize_minimal (nptl-init.c:467) > ==9202== by 0x5307408: ??? (in /usr/lib64/libpthread-2.17.so) > ==9202== by 0x50F9F5F: ??? (in /usr/lib64/libnss_sss.so.2) > ==9202== by 0x4F56F1: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash) > ==9202== by 0x4F5836: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash) > ==9202== by 0x4DBB59: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash) > ==9202== by 0x4D9E65: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash) > ==9202== by 0x4DB476: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash) > ==9202== by 0x4DDA86: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash) > ==9202== by 0x4D9E65: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash) > ==9202== by 0x4DD8D6: ??? (in /localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash) > ~~~~~~~~~~~~~~~~~~~~~~~ > > libnss_sss is used because on my workstation we use sssd for user > authentication with LDAP. Interesting. How does libnss_sss.so get loaded? Is it specified in /etc/ld.so.preload, /etc/nsswitch.conf, or some other global configuration file? Could you this time replace ‘valgrind’ with ‘strace -f -o log’ in ‘pre-inst-env’, and send that log? I fail to see how this library gets loaded. > On a possibly related note, Emacs installed through Guix on this > Fedora 21 workstation fails to find my user's home directory (which is > mounted over NFS). Upon starting Emacs I get this error: "Error > (initialization): User rwurmus has no home directory"; "--debug-init" > does not make any difference. HOME is set, of course. I wonder if > this is a helpful clue. Does (getpw (getenv "USER")) work on this system? Thanks, Ludo’.
bug-guix <at> gnu.org:bug#19780; Package guix.
(Fri, 13 Feb 2015 10:35:01 GMT) Full text and rfc822 format available.Message #74 received at 19780 <at> debbugs.gnu.org (full text, mbox):
From: Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de> To: Ludovic Courtès <ludo <at> gnu.org> Cc: 19780 <at> debbugs.gnu.org Subject: Re: bug#19780: 13 failing tests Date: Fri, 13 Feb 2015 11:33:51 +0100
[Message part 1 (text/plain, inline)]
Ludovic Courtès writes:
>> libnss_sss is used because on my workstation we use sssd for user
>> authentication with LDAP.
>
> Interesting. How does libnss_sss.so get loaded? Is it specified in
> /etc/ld.so.preload, /etc/nsswitch.conf, or some other global
> configuration file?
It is mentioned in /etc/nsswitch.conf:
~~~~~~~
...
passwd: files sss
shadow: files sss
group: files sss
services: files sss
netgroup: files sss
...
~~~~~~~
> Could you this time replace ‘valgrind’ with ‘strace -f -o log’ in
> ‘pre-inst-env’, and send that log? I fail to see how this library gets
> loaded.
Attached is the log, but I'm afraid it may not be very helpful.
>> On a possibly related note, Emacs installed through Guix on this
>> Fedora 21 workstation fails to find my user's home directory (which is
>> mounted over NFS). Upon starting Emacs I get this error: "Error
>> (initialization): User rwurmus has no home directory"; "--debug-init"
>> does not make any difference. HOME is set, of course. I wonder if
>> this is a helpful clue.
>
> Does (getpw (getenv "USER")) work on this system?
Yes, with my system guile (2.0.11) it returns my full user record.
scheme@(guile-user)> (getpw (getenv "USER"))
$1 = #("rwurmus" "*" 12345 12345 "Wurmus, Ricardo" "/home/rwurmus" "/bin/bash")
In Emacs (installed via Guix) the above error is shown, but (getenv
"HOME") returns my home dir and (getenv "USER") my user name, just as
they should.
~~ Ricardo
[strace.log (text/plain, attachment)]
bug-guix <at> gnu.org:bug#19780; Package guix.
(Fri, 13 Feb 2015 13:21:01 GMT) Full text and rfc822 format available.Message #77 received at 19780 <at> debbugs.gnu.org (full text, mbox):
From: ludo <at> gnu.org (Ludovic Courtès) To: Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de> Cc: 19780 <at> debbugs.gnu.org Subject: Re: bug#19780: 13 failing tests Date: Fri, 13 Feb 2015 14:20:20 +0100
Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de> skribis:
> 17814 execve("/localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash", ["nakn26p520psw7jawgfv74wm34dn6kxj"..., "/localhome/rwurmus-tmp/guix/test"...], [/* 11 vars */]) = 0
[...]
> 17814 connect(3, {sa_family=AF_LOCAL, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
> 17814 close(3) = 0
> 17814 open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
> 17814 fstat(3, {st_mode=S_IFREG|0644, st_size=1861, ...}) = 0
> 17814 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fed42e86000
> 17814 read(3, "#\n# /etc/nsswitch.conf\n#\n# An ex"..., 4096) = 1861
> 17814 read(3, "", 4096) = 0
> 17814 close(3) = 0
> 17814 munmap(0x7fed42e86000, 4096) = 0
> 17814 open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
> 17814 fstat(3, {st_mode=S_IFREG|0644, st_size=33941, ...}) = 0
> 17814 mmap(NULL, 33941, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fed42e7e000
> 17814 close(3) = 0
> 17814 open("/lib64/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 3
And from there we’re doomed.
Could you download
<ftp://alpha.gnu.org:/gnu/guix/bootstrap/x86_64-linux/20131110/static-binaries.tar.xz>
and replace ‘gnu/packages/bootstrap/x86_64-linux/bash’ with the ‘bash’
file from that tarball (make it executable), and then try again?
I believe the problem is that these binaries date from before commit
d3b59727 (Jan. 2013), which disabled dynamic NSS support in bootstrap
binaries.
Thanks for your help!
Ludo’.
bug-guix <at> gnu.org:bug#19780; Package guix.
(Fri, 13 Feb 2015 13:24:02 GMT) Full text and rfc822 format available.Message #80 received at 19780 <at> debbugs.gnu.org (full text, mbox):
From: ludo <at> gnu.org (Ludovic Courtès) To: Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de> Cc: 19780 <at> debbugs.gnu.org Subject: Re: bug#19780: 13 failing tests Date: Fri, 13 Feb 2015 14:23:45 +0100
Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de> skribis:
> Yes, with my system guile (2.0.11) it returns my full user record.
>
> scheme@(guile-user)> (getpw (getenv "USER"))
> $1 = #("rwurmus" "*" 12345 12345 "Wurmus, Ricardo" "/home/rwurmus" "/bin/bash")
And what about the Guix-built Guile?
Thanks,
Ludo’.
ludo <at> gnu.org (Ludovic Courtès)
to control <at> debbugs.gnu.org.
(Fri, 13 Feb 2015 13:27:02 GMT) Full text and rfc822 format available.bug-guix <at> gnu.org:bug#19780; Package guix.
(Fri, 13 Feb 2015 15:15:02 GMT) Full text and rfc822 format available.Message #85 received at 19780 <at> debbugs.gnu.org (full text, mbox):
From: Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de> To: Ludovic Courtès <ludo <at> gnu.org> Cc: 19780 <at> debbugs.gnu.org Subject: Re: bug#19780: 13 failing tests Date: Fri, 13 Feb 2015 16:14:36 +0100
Ludovic Courtès writes:
> Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de> skribis:
>
>> Yes, with my system guile (2.0.11) it returns my full user record.
>>
>> scheme@(guile-user)> (getpw (getenv "USER"))
>> $1 = #("rwurmus" "*" 12345 12345 "Wurmus, Ricardo" "/home/rwurmus" "/bin/bash")
>
> And what about the Guix-built Guile?
I had to install it first:
~~~~~~~~~~~~~~~
scheme@(guile-user)> (getpw (getenv "USER"))
ERROR: In procedure getpw:
ERROR: In procedure getpw: entry not found
Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue.
scheme@(guile-user) [1]> ,bt
0 (getpw "rwurmus")
scheme@(guile-user) [1]>
~~~~~~~~~~~~~~~
~~ Ricardo
bug-guix <at> gnu.org:bug#19780; Package guix.
(Fri, 13 Feb 2015 22:39:02 GMT) Full text and rfc822 format available.Message #88 received at 19780 <at> debbugs.gnu.org (full text, mbox):
From: ludo <at> gnu.org (Ludovic Courtès) To: Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de> Cc: 19780 <at> debbugs.gnu.org Subject: Re: bug#19780: 13 failing tests Date: Fri, 13 Feb 2015 23:38:52 +0100
Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de> skribis:
> Ludovic Courtès writes:
>
>> Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de> skribis:
>>
>>> Yes, with my system guile (2.0.11) it returns my full user record.
>>>
>>> scheme@(guile-user)> (getpw (getenv "USER"))
>>> $1 = #("rwurmus" "*" 12345 12345 "Wurmus, Ricardo" "/home/rwurmus" "/bin/bash")
>>
>> And what about the Guix-built Guile?
>
> I had to install it first:
>
> ~~~~~~~~~~~~~~~
> scheme@(guile-user)> (getpw (getenv "USER"))
> ERROR: In procedure getpw:
> ERROR: In procedure getpw: entry not found
>
> Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue.
> scheme@(guile-user) [1]> ,bt
> 0 (getpw "rwurmus")
> scheme@(guile-user) [1]>
> ~~~~~~~~~~~~~~~
Is nscd running on this system? Seems like not.
Ludo’.
bug-guix <at> gnu.org:bug#19780; Package guix.
(Thu, 26 Feb 2015 16:50:02 GMT) Full text and rfc822 format available.Message #91 received at 19780 <at> debbugs.gnu.org (full text, mbox):
From: ludo <at> gnu.org (Ludovic Courtès) To: Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de> Cc: 19780 <at> debbugs.gnu.org Subject: Re: bug#19780: 13 failing tests Date: Thu, 26 Feb 2015 17:49:15 +0100
ludo <at> gnu.org (Ludovic Courtès) skribis:
> Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de> skribis:
>
>> 17814 execve("/localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash", ["nakn26p520psw7jawgfv74wm34dn6kxj"..., "/localhome/rwurmus-tmp/guix/test"...], [/* 11 vars */]) = 0
>
> [...]
>
>> 17814 connect(3, {sa_family=AF_LOCAL, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
>> 17814 close(3) = 0
>> 17814 open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
>> 17814 fstat(3, {st_mode=S_IFREG|0644, st_size=1861, ...}) = 0
>> 17814 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fed42e86000
>> 17814 read(3, "#\n# /etc/nsswitch.conf\n#\n# An ex"..., 4096) = 1861
>> 17814 read(3, "", 4096) = 0
>> 17814 close(3) = 0
>> 17814 munmap(0x7fed42e86000, 4096) = 0
>> 17814 open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
>> 17814 fstat(3, {st_mode=S_IFREG|0644, st_size=33941, ...}) = 0
>> 17814 mmap(NULL, 33941, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fed42e7e000
>> 17814 close(3) = 0
>> 17814 open("/lib64/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 3
>
> And from there we’re doomed.
>
> Could you download
> <ftp://alpha.gnu.org:/gnu/guix/bootstrap/x86_64-linux/20131110/static-binaries.tar.xz>
> and replace ‘gnu/packages/bootstrap/x86_64-linux/bash’ with the ‘bash’
> file from that tarball (make it executable), and then try again?
Ping! :-)
‘core-updates’ being opened, it would be the right time to update those
binaries if that solves the problem.
Thanks,
Ludo’.
bug-guix <at> gnu.org:bug#19780; Package guix.
(Sat, 28 Feb 2015 21:59:02 GMT) Full text and rfc822 format available.Message #94 received at 19780 <at> debbugs.gnu.org (full text, mbox):
From: Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de> To: Ludovic Courtès <ludo <at> gnu.org> Cc: 19780 <at> debbugs.gnu.org Subject: Re: bug#19780: 13 failing tests Date: Sat, 28 Feb 2015 22:58:29 +0100
Ludovic Courtès writes:
> ludo <at> gnu.org (Ludovic Courtès) skribis:
>
>> Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de> skribis:
>>
>>> 17814 execve("/localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash", ["nakn26p520psw7jawgfv74wm34dn6kxj"..., "/localhome/rwurmus-tmp/guix/test"...], [/* 11 vars */]) = 0
>>
>> [...]
>>
>>> 17814 connect(3, {sa_family=AF_LOCAL, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
>>> 17814 close(3) = 0
>>> 17814 open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
>>> 17814 fstat(3, {st_mode=S_IFREG|0644, st_size=1861, ...}) = 0
>>> 17814 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fed42e86000
>>> 17814 read(3, "#\n# /etc/nsswitch.conf\n#\n# An ex"..., 4096) = 1861
>>> 17814 read(3, "", 4096) = 0
>>> 17814 close(3) = 0
>>> 17814 munmap(0x7fed42e86000, 4096) = 0
>>> 17814 open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
>>> 17814 fstat(3, {st_mode=S_IFREG|0644, st_size=33941, ...}) = 0
>>> 17814 mmap(NULL, 33941, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fed42e7e000
>>> 17814 close(3) = 0
>>> 17814 open("/lib64/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 3
>>
>> And from there we’re doomed.
>>
>> Could you download
>> <ftp://alpha.gnu.org:/gnu/guix/bootstrap/x86_64-linux/20131110/static-binaries.tar.xz>
>> and replace ‘gnu/packages/bootstrap/x86_64-linux/bash’ with the ‘bash’
>> file from that tarball (make it executable), and then try again?
>
> Ping! :-)
>
> ‘core-updates’ being opened, it would be the right time to update those
> binaries if that solves the problem.
Sorry for dropping the ball.
I tested with the new static binaries but still could not run the tests
successfully. I hope to get back to work on this on Monday again and
provide more helpful feedback.
~~ Ricardo
bug-guix <at> gnu.org:bug#19780; Package guix.
(Mon, 02 Mar 2015 15:58:01 GMT) Full text and rfc822 format available.Message #97 received at 19780 <at> debbugs.gnu.org (full text, mbox):
From: Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de> To: Ludovic Courtès <ludo <at> gnu.org> Cc: 19780 <at> debbugs.gnu.org Subject: Re: bug#19780: 13 failing tests Date: Mon, 2 Mar 2015 16:57:11 +0100
Ludovic Courtès writes:
> Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de> skribis:
>
>> 17814 execve("/localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash", ["nakn26p520psw7jawgfv74wm34dn6kxj"..., "/localhome/rwurmus-tmp/guix/test"...], [/* 11 vars */]) = 0
>
> [...]
>
>> 17814 connect(3, {sa_family=AF_LOCAL, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
>> 17814 close(3) = 0
>> 17814 open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
>> 17814 fstat(3, {st_mode=S_IFREG|0644, st_size=1861, ...}) = 0
>> 17814 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fed42e86000
>> 17814 read(3, "#\n# /etc/nsswitch.conf\n#\n# An ex"..., 4096) = 1861
>> 17814 read(3, "", 4096) = 0
>> 17814 close(3) = 0
>> 17814 munmap(0x7fed42e86000, 4096) = 0
>> 17814 open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
>> 17814 fstat(3, {st_mode=S_IFREG|0644, st_size=33941, ...}) = 0
>> 17814 mmap(NULL, 33941, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fed42e7e000
>> 17814 close(3) = 0
>> 17814 open("/lib64/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 3
>
> And from there we’re doomed.
>
> Could you download
> <ftp://alpha.gnu.org:/gnu/guix/bootstrap/x86_64-linux/20131110/static-binaries.tar.xz>
> and replace ‘gnu/packages/bootstrap/x86_64-linux/bash’ with the ‘bash’
> file from that tarball (make it executable), and then try again?
>
> I believe the problem is that these binaries date from before commit
> d3b59727 (Jan. 2013), which disabled dynamic NSS support in bootstrap
> binaries.
With the bash from that tarball I no longer get a segfault related to
NSS, but I still get a segfault :-/
~~~~~~~~~~~~~~~~~~~~~~
[rwurmus <at> guix-builder:/localhome/rwurmus-tmp/guix] (548) $ ./test-env guix build guile-bootstrap
accepted connection from pid 9363, uid 22840
substitute-binary: warning: authentication and authorization of substitutes disabled!
substitute-binary: guix substitute-binary: warning: ACL for archive imports seems to be uninitialized, substitutes may be unavailable
substitute-binary: updating list of substitutes from 'file:///localhome/rwurmus-tmp/guix/test-tmp/var/9357/substituter-data'...
The following derivation will be built:
/localhome/rwurmus-tmp/guix/test-tmp/store/mfljxqix4a8lqkfcpchrnr8yz4ijwcq0-guile-bootstrap-2.0.drv
@ build-started /localhome/rwurmus-tmp/guix/test-tmp/store/mfljxqix4a8lqkfcpchrnr8yz4ijwcq0-guile-bootstrap-2.0.drv - x86_64-linux /localhome/rwurmus-tmp/guix/test-tmp/var/log/guix/drvs/mf//ljxqix4a8lqkfcpchrnr8yz4ijwcq0-guile-bootstrap-2.0.drv.bz2
unpacking bootstrap Guile to '/localhome/rwurmus-tmp/guix/test-tmp/store/zwq7a0qpq4fljviyycn4zdryqqx2yjn1-guile-bootstrap-2.0'...
/localhome/rwurmus-tmp/guix/test-tmp/store/qa6832c56pfysmdjbw1x1fbnxjc7azj5-build-bootstrap-guile.sh: line 5: 9416 Done /localhome/rwurmus-tmp/guix/test-tmp/store/hjdspi89n2d27lx9c4k3387iip4vk604-xz -dc < /localhome/rwurmus-tmp/guix/test-tmp/store/mhmv9m38s69c7d61hxap2hba928q3hyz-guile-2.0.9.tar.xz
9417 Segmentation fault | /localhome/rwurmus-tmp/guix/test-tmp/store/gb5wsd2yr71l075klclydfnkj7qil2yw-tar xv
/localhome/rwurmus-tmp/guix/test-tmp/store/qa6832c56pfysmdjbw1x1fbnxjc7azj5-build-bootstrap-guile.sh: line 8: /localhome/rwurmus-tmp/guix/test-tmp/store/zwq7a0qpq4fljviyycn4zdryqqx2yjn1-guile-bootstrap-2.0/bin/guile: No such file or directory
builder for `/localhome/rwurmus-tmp/guix/test-tmp/store/mfljxqix4a8lqkfcpchrnr8yz4ijwcq0-guile-bootstrap-2.0.drv' failed with exit code 127
@ build-failed /localhome/rwurmus-tmp/guix/test-tmp/store/mfljxqix4a8lqkfcpchrnr8yz4ijwcq0-guile-bootstrap-2.0.drv - 1 builder for `/localhome/rwurmus-tmp/guix/test-tmp/store/mfljxqix4a8lqkfcpchrnr8yz4ijwcq0-guile-bootstrap-2.0.drv' failed with exit code 127
killing process 9412
guix build: error: build failed: build of `/localhome/rwurmus-tmp/guix/test-tmp/store/mfljxqix4a8lqkfcpchrnr8yz4ijwcq0-guile-bootstrap-2.0.drv' failed
13 operations
./test-env: line 1: 9362 Terminated "/localhome/rwurmus-tmp/guix/pre-inst-env" "/localhome/rwurmus-tmp/guix/guix-daemon" --disable-chroot --substitute-urls="$GUIX_BINARY_SUBSTITUTE_URL"
[rwurmus <at> guix-builder:/localhome/rwurmus-tmp/guix] (549) $
~~~~~~~~~~~~~~~~~~~~~~~~~~
The segfault seems to be in tar. After replacing both tar and xz with
the versions from the tarball, however, the segfault disappears. I'm
now running "make check" again. So far it looks good as it takes longer
than before.
~~ Ricardo
bug-guix <at> gnu.org:bug#19780; Package guix.
(Tue, 03 Mar 2015 08:05:02 GMT) Full text and rfc822 format available.Message #100 received at 19780 <at> debbugs.gnu.org (full text, mbox):
From: ludo <at> gnu.org (Ludovic Courtès) To: Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de> Cc: 19780 <at> debbugs.gnu.org Subject: Re: bug#19780: 13 failing tests Date: Tue, 03 Mar 2015 09:04:06 +0100
Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de> skribis:
> Ludovic Courtès writes:
>
>> Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de> skribis:
>>
>>> 17814 execve("/localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash", ["nakn26p520psw7jawgfv74wm34dn6kxj"..., "/localhome/rwurmus-tmp/guix/test"...], [/* 11 vars */]) = 0
>>
>> [...]
>>
>>> 17814 connect(3, {sa_family=AF_LOCAL, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
>>> 17814 close(3) = 0
>>> 17814 open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
>>> 17814 fstat(3, {st_mode=S_IFREG|0644, st_size=1861, ...}) = 0
>>> 17814 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fed42e86000
>>> 17814 read(3, "#\n# /etc/nsswitch.conf\n#\n# An ex"..., 4096) = 1861
>>> 17814 read(3, "", 4096) = 0
>>> 17814 close(3) = 0
>>> 17814 munmap(0x7fed42e86000, 4096) = 0
>>> 17814 open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
>>> 17814 fstat(3, {st_mode=S_IFREG|0644, st_size=33941, ...}) = 0
>>> 17814 mmap(NULL, 33941, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fed42e7e000
>>> 17814 close(3) = 0
>>> 17814 open("/lib64/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 3
>>
>> And from there we’re doomed.
>>
>> Could you download
>> <ftp://alpha.gnu.org:/gnu/guix/bootstrap/x86_64-linux/20131110/static-binaries.tar.xz>
>> and replace ‘gnu/packages/bootstrap/x86_64-linux/bash’ with the ‘bash’
>> file from that tarball (make it executable), and then try again?
>>
>> I believe the problem is that these binaries date from before commit
>> d3b59727 (Jan. 2013), which disabled dynamic NSS support in bootstrap
>> binaries.
>
> With the bash from that tarball I no longer get a segfault related to
> NSS, but I still get a segfault :-/
[...]
> The segfault seems to be in tar. After replacing both tar and xz with
> the versions from the tarball, however, the segfault disappears. I'm
> now running "make check" again. So far it looks good as it takes longer
> than before.
Ah, good.
In the next ‘core-updates’ round, we’ll update those binaries, then.
Thanks for testing!
Ludo’.
ludo <at> gnu.org (Ludovic Courtès):Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de>:Message #105 received at 19780-done <at> debbugs.gnu.org (full text, mbox):
From: ludo <at> gnu.org (Ludovic Courtès) To: Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de> Cc: 19780-done <at> debbugs.gnu.org Subject: Re: bug#19780: 13 failing tests Date: Tue, 31 Mar 2015 23:18:40 +0200
[Message part 1 (text/plain, inline)]
Commit 4c0d38b updates those 4 binaries for i686 and x86_64. I took
them from
<ftp://alpha.gnu.org:/gnu/guix/bootstrap/{x86_64,i686}-linux/20131110/static-binaries.tar.xz>.
The commit itself is signed (see “git show --show-signature 4c0d38b”.)
Thanks,
Ludo’.
[signature.asc (application/pgp-signature, inline)]
Debbugs Internal Request <help-debbugs <at> gnu.org>
to internal_control <at> debbugs.gnu.org.
(Wed, 29 Apr 2015 11:24:06 GMT) Full text and rfc822 format available.Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de>
to control <at> debbugs.gnu.org.
(Tue, 13 Oct 2015 09:52:01 GMT) Full text and rfc822 format available.bug-guix <at> gnu.org:bug#19780; Package guix.
(Tue, 13 Oct 2015 10:00:04 GMT) Full text and rfc822 format available.Message #112 received at 19780 <at> debbugs.gnu.org (full text, mbox):
From: Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de> To: <19780 <at> debbugs.gnu.org> Subject: “User has no home directory” (was: bug#19780: 13 failing tests) Date: Tue, 13 Oct 2015 11:59:30 +0200
Hi Ludo,
I can confirm that the error disappears when nscd is running. Emacs no
longer tells me
Error (initialization): User rwurmus has no home directory
when starting it as long as nscd is running.
I would like to note that the version of Emacs that is available through
Fedora repositories does not need nscd to run (this is on the same
machine). The error only appears when nscd is not running and the Emacs
installed via Guix is used.
Thanks for the help! Now that I’m sure that this is not a general
problem I can prepare to replace Fedora with GuixSD on my office
workstation.
~~ Ricardo
bug-guix <at> gnu.org:bug#19780; Package guix.
(Tue, 13 Oct 2015 12:30:02 GMT) Full text and rfc822 format available.Message #115 received at 19780 <at> debbugs.gnu.org (full text, mbox):
From: ludo <at> gnu.org (Ludovic Courtès) To: Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de> Cc: 19780 <at> debbugs.gnu.org Subject: Re: “User has no home directory” Date: Tue, 13 Oct 2015 14:29:25 +0200
Ricardo Wurmus <ricardo.wurmus <at> mdc-berlin.de> skribis: > I can confirm that the error disappears when nscd is running. Emacs no > longer tells me > > Error (initialization): User rwurmus has no home directory > > when starting it as long as nscd is running. > > I would like to note that the version of Emacs that is available through > Fedora repositories does not need nscd to run (this is on the same > machine). The error only appears when nscd is not running and the Emacs > installed via Guix is used. Earlier, you wrote: --8<---------------cut here---------------start------------->8--- It is mentioned in /etc/nsswitch.conf: ~~~~~~~ ... passwd: files sss shadow: files sss group: files sss services: files sss netgroup: files sss ... ~~~~~~~ --8<---------------cut here---------------end--------------->8--- (See <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19780#74>.) What happens is that libnss_sss.so was being loaded in your Emacs process. However, the Emacs process was linked against Guix’s libc, whereas libnss_sss.so was linked against Fedora’s libc. Hence the crash. When nscd is running, NSS extensions are loaded in the nscd process so there is no such problem. > Thanks for the help! Now that I’m sure that this is not a general > problem I can prepare to replace Fedora with GuixSD on my office > workstation. \o/ Thanks! Ludo’.
Debbugs Internal Request <help-debbugs <at> gnu.org>
to internal_control <at> debbugs.gnu.org.
(Wed, 11 Nov 2015 12:24:04 GMT) Full text and rfc822 format available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.