Non-deterministic Gash error in ‘gcc-mesboot-4.9.4’

  • Open
  • quality assurance status badge
Details
2 participants
  • Ludovic Courtès
  • Ludovic Courtès
Owner
unassigned
Submitted by
Ludovic Courtès
Severity
normal
L
L
Ludovic Courtès wrote on 18 Jan 23:08 +0100
Non-deterministic Gash error in ‘gcc-mesboot-4 .9.4’
(address . bug-guix@gnu.org)
87msfnsrli.fsf@inria.fr
Hello,

I stumbled upon this interesting non-deterministic failure while
building ‘gcc-mesboot-4.9.4.drv’ on current ‘core-packages-team’ (which
is unchanged compared to ‘master’):

Toggle snippet (88 lines)
source directory: "/tmp/guix-build-gcc-mesboot-4.9.4.drv-0/gcc-4.9.4" (relative from build: ".")
build directory: "/tmp/guix-build-gcc-mesboot-4.9.4.drv-0/gcc-4.9.4"
configure flags: ("CONFIG_SHELL=/gnu/store/bhmkf29xki04mmydpm0axpbh35md4vfb-gash-boot-0.3.0/bin/bash" "SHELL=/gnu/store/bhmkf29xki04mmydpm0axpbh35md4vfb-gash-boot-0.3.0/bin/bash" "--prefix=/gnu/store/mgbd56zvid129vkk8l9zir7pf46r5038-gcc-mesboot-4.9.4" "--enable-fast-install" "--build=x86_64-unknown-linux-gnu" "--prefix=/gnu/store/mgbd56zvid129vkk8l9zir7pf46r5038-gcc-mesboot-4.9.4" "--build=i686-unknown-linux-gnu" "--host=i686-unknown-linux-gnu" "--with-host-libstdcxx=-lsupc++" "--with-native-system-header-dir=/gnu/store/qxp7icgwbn1hqqwvkan7aljgzfn439zh-glibc-mesboot-2.16.0/include" "--with-build-sysroot=/gnu/store/qxp7icgwbn1hqqwvkan7aljgzfn439zh-glibc-mesboot-2.16.0/include" "--disable-bootstrap" "--disable-decimal-float" "--disable-libatomic" "--disable-libcilkrts" "--disable-libgomp" "--disable-libitm" "--disable-libmudflap" "--disable-libquadmath" "--disable-libsanitizer" "--disable-libssp" "--disable-libvtv" "--disable-lto" "--disable-lto-plugin" "--disable-multilib" "--disable-plugin" "--disable-threads" "--enable-languages=c,c++" "--enable-static" "--enable-shared" "--enable-threads=single" "--disable-libstdcxx-pch" "--disable-build-with-cxx")
Backtrace:
In gash/eval.scm:
221: 19 [eval-sh (<sh-set!> ("ac_useropt" (<sh-cmd-sub> #)))]
In srfi/srfi-1.scm:
642: 18 [for-each #<procedure 1502320 at gash/eval.scm:221:17 (name word)> # #]
In gash/eval.scm:
222: 17 [#<procedure 1502320 at gash/eval.scm:221:17 (name word)> "ac_useropt" #]
131: 16 [eval-word (<sh-cmd-sub> (<sh-pipeline> # #)) #:output string ...]
121: 15 [expand-word (<sh-cmd-sub> (<sh-pipeline> # #)) #:output string ...]
In gash/shell.scm:
289: 14 [sh:substitute-command #<procedure 15022a0 at gash/eval.scm:129:35 ()>]
270: 13 [%subshell #<procedure v ()>]
In ice-9/boot-9.scm:
157: 12 [catch quit #<procedure v ()> ...]
In ice-9/r4rs.scm:
176: 11 [with-output-to-port #<variable 13a02e0 value: #<output: file 39>> ...]
In srfi/srfi-1.scm:
619: 10 [for-each #<procedure eval-sh (exp)> ((<sh-pipeline> # #))]
In gash/shell.scm:
344: 9 [sh:pipeline #<procedure 1506f40 at gash/eval.scm:149:6 ()> ...]
310: 8 [plumb #<input: #{read pipe}# 36> #f ...]
270: 7 [%subshell #<procedure thunk* ()>]
In ice-9/boot-9.scm:
157: 6 [catch quit #<procedure thunk* ()> ...]
In gash/shell.scm:
316: 5 [thunk*]
129: 4 [sh:exec-let () "sed" "s/[-+.]/_/g"]
92: 3 [exec-utility () ...]
In srfi/srfi-1.scm:
616: 2 [for-each #<procedure ec3b20 at gash/shell.scm:70:12 (i)> (0 1 2 ...)]
In ice-9/boot-9.scm:
1473: 1 [dup->port #<input: file 38> "r" 7]
In unknown file:
?: 0 [fdopen 7 "r"]

ERROR: In procedure fdopen:
ERROR: In procedure scm_fdes_to_port: Bad file descriptor
Backtrace:
In gash/eval.scm:
221: 19 [eval-sh (<sh-set!> ("ac_useropt" (<sh-cmd-sub> #)))]
In srfi/srfi-1.scm:
642: 18 [for-each #<procedure 1502320 at gash/eval.scm:221:17 (name word)> # #]
In gash/eval.scm:
222: 17 [#<procedure 1502320 at gash/eval.scm:221:17 (name word)> "ac_useropt" #]
131: 16 [eval-word (<sh-cmd-sub> (<sh-pipeline> # #)) #:output string ...]
121: 15 [expand-word (<sh-cmd-sub> (<sh-pipeline> # #)) #:output string ...]
In gash/shell.scm:
289: 14 [sh:substitute-command #<procedure 15022a0 at gash/eval.scm:129:35 ()>]
270: 13 [%subshell #<procedure v ()>]
In ice-9/boot-9.scm:
157: 12 [catch quit #<procedure v ()> ...]
In ice-9/r4rs.scm:
176: 11 [with-output-to-port #<variable 13a02e0 value: #<output: file 39>> ...]
In srfi/srfi-1.scm:
619: 10 [for-each #<procedure eval-sh (exp)> ((<sh-pipeline> # #))]
In gash/shell.scm:
347: 9 [sh:pipeline #<procedure 1506f40 at gash/eval.scm:149:6 ()> ...]
310: 8 [plumb #f #<output: #{write pipe}# 38> ...]
270: 7 [%subshell #<procedure thunk* ()>]
In ice-9/boot-9.scm:
157: 6 [catch quit #<procedure thunk* ()> ...]
In gash/shell.scm:
316: 5 [thunk*]
129: 4 [sh:exec-let () "printf" "%s\\n" "libsanitizer"]
92: 3 [exec-utility () ...]
In srfi/srfi-1.scm:
616: 2 [for-each #<procedure ec3b20 at gash/shell.scm:70:12 (i)> (0 1 2 ...)]
In ice-9/boot-9.scm:
1473: 1 [dup->port #<input: file 36> "r" 7]
In unknown file:
?: 0 [fdopen 7 "r"]

ERROR: In procedure fdopen:
ERROR: In procedure scm_fdes_to_port: Bad file descriptor
checking build system type... i686-unknown-linux-gnu
checking host system type... i686-unknown-linux-gnu
checking target system type... i686-unknown-linux-gnu
checking for a BSD-compatible install... ./install-sh -c
checking whether ln works... yes
checking whether ln -s works... yes
checking for a sed that does not truncate output... /gnu/store/i61mvrw30k8ng8hxym8s180nydnsbji6-gash-utils-boot-0.2.0/bin/sed
checking for gawk... gawk
checking for libsanitizer support... yes

What happens is that Gash crashes in the middle of a substitution on
$ac_useropt. As a result, ‘--disable-libsanitizer’ (and other options,
it seems) are discarded, hence the “libsanitizer support... yes” line.
Hours later, build fails while trying to build libsanitizer.

Any idea what could cause EBADF?

Thanks,
Ludo’.
L
L
Ludovic Courtès wrote on 19 Jan 19:24 +0100
Re: bug#75658: Non-deterministic Gash error in ‘gcc-mesboot-4.9.4’
(address . 75658@debbugs.gnu.org)
87wmeqpspy.fsf@gnu.org
Ludovic Courtès <ludovic.courtes@inria.fr> skribis:

Toggle quote (4 lines)
> I stumbled upon this interesting non-deterministic failure while
> building ‘gcc-mesboot-4.9.4.drv’ on current ‘core-packages-team’ (which
> is unchanged compared to ‘master’):

Just got another one:

Toggle snippet (46 lines)
checking for struct sigaction.sa_sigaction... yes
checking for volatile sig_atomic_t... yes
checking for sighandler_t... yes
checking for sigprocmask... (cached) yes
checking whether sleep is declared... yes
checking for working sleep... yes
checking for socklen_t... Backtrace:
In gash/shell.scm:
129: 19 [sh:exec-let () "ac_fn_c_try_compile" "2817"]
In gash/environment.scm:
215: 18 [save-variables-excursion () ...]
292: 17 [with-arguments # #<procedure 2210f00 at gash/shell.scm:145:25 ()>]
389: 16 [call-with-return #<procedure 2210e40 at gash/shell.scm:147:28 ()>]
In srfi/srfi-1.scm:
619: 15 [for-each #<procedure eval-sh (exp)> ((<sh-begin> # # # ...))]
619: 14 [for-each #<procedure eval-sh (exp)> (# # # # ...)]
In gash/shell.scm:
441: 13 [sh:cond # #]
55: 12 [without-errexit #<procedure 13185e0 at gash/eval.scm:149:6 ()>]
372: 11 [sh:and #<procedure 1318560 at gash/eval.scm:149:6 ()> ...]
55: 10 [without-errexit #<procedure 1318560 at gash/eval.scm:149:6 ()>]
372: 9 [sh:and #<procedure 1318500 at gash/eval.scm:149:6 ()> ...]
55: 8 [without-errexit #<procedure 1318500 at gash/eval.scm:149:6 ()>]
In srfi/srfi-1.scm:
616: 7 [for-each #<procedure eval-sh (exp)> (# # # # ...)]
619: 6 [for-each #<procedure eval-sh (exp)> (# # #)]
In gash/shell.scm:
245: 5 [#<procedure 1f63030 at gash/shell.scm:239:17 ()>]
129: 4 [sh:exec-let () "grep" "-v" "^ *+" "conftest.err"]
92: 3 [exec-utility () ...]
In srfi/srfi-1.scm:
616: 2 [for-each #<procedure ea9a60 at gash/shell.scm:70:12 (i)> (0 1 2 ...)]
In ice-9/boot-9.scm:
1473: 1 [dup->port #<input: file 20> "r" 7]
In unknown file:
?: 0 [fdopen 7 "r"]

ERROR: In procedure fdopen:
ERROR: In procedure scm_fdes_to_port: Bad file descriptor
yes
checking whether symlink handles trailing slash correctly... yes
checking whether <sys/ioctl.h> declares ioctl... yes
checking for unsetenv... yes
checking for unsetenv() return type... int

That one likely doesn’t change the build outcome since it still
determines that ‘socklen_t’ is defined, but it sounds a bit like a dice
roll.

Ludo’.
L
L
Ludovic Courtès wrote 4 days ago
control message for bug #75518
(address . control@debbugs.gnu.org)
877c636r2f.fsf@gnu.org
block 75518 by 75658
quit
?
Your comment

Commenting via the web interface is currently disabled.

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

To respond to this issue using the mumi CLI, first switch to it
mumi current 75658
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