kill emerge init,1 └─sudo,30972 /opt/tb/bin/bwrap.sh -m /home/tinderbox/img/17.1_desktop_plasma_systemd-20231114-175506 -e /opt/tb/bin/job.sh └─bwrap.sh,31003 /opt/tb/bin/bwrap.sh -m /home/tinderbox/img/17.1_desktop_plasma_systemd-20231114-175506 -e /opt/tb/bin/job.sh └─bwrap,31195 --clearenv --setenv MAILTO tinderbox --setenv PATH /usr/sbin:/usr/bin:/sbin:/bin --setenv SHELL /bin/bash --setenv TERM linux --hostname 17-1-desktop-plasma-systemd-2023111 └─bwrap,31200 --clearenv --setenv MAILTO tinderbox --setenv PATH /usr/sbin:/usr/bin:/sbin:/bin --setenv SHELL /bin/bash --setenv TERM linux --hostname 17-1-desktop-plasma-systemd-202 └─entrypoint,31212 /root/entrypoint └─timeout,17283 --signal=15 --kill-after=5m 48h bash -c emerge --update dev-lisp/alexandria └─emerge,17286 /usr/lib/python-exec/python3.11/emerge --update dev-lisp/alexandria ├─python3.11,4078 /usr/lib/portage/python3.11/pid-ns-init 1743 │ └─python3.11,4091 /usr/lib/portage/python3.11/pid-ns-init 250 250 250 18 0,1,2 /usr/bin/sandbox [dev-lisp/sbcl-2.3.9] sandbox /usr/lib/portage/python3.11/ebuild │ └─sandbox,4135,portage /usr/lib/portage/python3.11/ebuild.sh compile │ └─bash,4139 /usr/lib/portage/python3.11/ebuild.sh compile │ └─bash,4199 /usr/lib/portage/python3.11/ebuild.sh compile │ └─make.sh,4228 ./make.sh sh /var/tmp/portage/dev-lisp/sbcl-2.3.9/work/sbcl-binary/run-sbcl.sh --no-sysinit --no-userinit --disable-debugger │ └─sh,24698 -x make-target-2.sh │ └─sbcl,18069 --noinform --core output/cold-sbcl.core --lose-on-corruption --no-sysinit --no-userinit --noprint └─bash,4080 -c ansifilter --ignore-clear; exec cat └─ansifilter,4083 --ignore-clear
Not again...
Added 2 bugs to See Also. Pretty sure we've had way more than that.
appeared recently at the tinderbox image 17.1_desktop_plasma_systemd-20231114-175506
------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.1_desktop_plasma_systemd-20231114-175506 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-14 * clang/llvm (if any): clang version 17.0.5 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm/17/bin Configuration file: /etc/clang/x86_64-pc-linux-gnu-clang.cfg /usr/lib/llvm/17 17.0.5 Python 3.11.6 Available Ruby profiles: [1] ruby31 (with Rubygems) * Available Rust versions: [1] rust-bin-1.73.0 * Available Java Virtual Machines: [1] openjdk-bin-8 [2] openjdk-bin-21 [3] openjdk-jre-bin-17 system-vm The Glorious Glasgow Haskell Compilation System, version 9.2.8 php cli (if any): go version go1.21.4 linux/amd64 HEAD of ::gentoo commit 8f5c5ffc76609143c20514f2ef860d1d6218a151 Author: Repository mirror & CI <repomirrorci@gentoo.org> Date: Fri Nov 17 02:02:03 2023 +0000 2023-11-17 02:02:03 UTC emerge -qpvO dev-lisp/sbcl [ebuild N ] dev-lisp/sbcl-2.3.9 USE="threads unicode zstd -debug -doc -source -system-bootstrap"
Created attachment 874923 [details] emerge-info.txt
Created attachment 874924 [details] dev-lisp:sbcl-2.3.9:20231117-040524.log
Created attachment 874925 [details] emerge-history.txt
Created attachment 874926 [details] etc.clang.tar.xz
Created attachment 874927 [details] etc.portage.tar.xz
Created attachment 874928 [details] qlist-info.txt
Created attachment 874929 [details] temp.tar.xz
The important lines in the log are the last ones: -------------------------------- fatal error encountered in SBCL pid 544 tid 544: GC invariant lost, file "immobile-space.c", line 442 Welcome to LDB, a low-level debugger for the Lisp runtime environment. -------------------------------- and the debugger is waiting for a user input ad infinitum. Something very wrong has happened during garbage collection. I've never seen such a thing.
Might be miscompiled.
(In reply to Sam James from comment #13) > Might be miscompiled. next image with same problem: 17.1_no_multilib_hardened-20231119-192004 16:17 h! (3 of 6) dev-lisp/sbcl-2.3.10
Is there some way to abort builds which wait for a user input? Add < /dev/null somewhere or something.
*** Bug 925948 has been marked as a duplicate of this bug. ***
(In reply to Andrey Grozin from comment #15) > Is there some way to abort builds which wait for a user input? Add < > /dev/null somewhere or something. should then be made in the ebuild, right?
