The futex facility returned an unexpected error code. error: could not compile `serde_json` Caused by: process didn't exit successfully: `rustc --crate-name build_script_build --edition=2018 /var/tmp/portage/dev-util/maturin-0.10.6/work/cargo_home/gentoo/serde_json-1.0.64/build.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type bin --emit=dep-info,link -C embed-bitcode=no -C debug-assertions=off --cfg 'feature="default"' --cfg 'feature="std"' --cfg 'feature="unbounded_depth"' -C metadata=d4ad0344b57abcdb -C extra-filename=-d4ad0344b57abcdb --out-dir /var/tmp/portage/dev-util/maturin-0.10.6/work/maturin-0.10.6/target/release/build/serde_json-d4ad0344b57abcdb -L dependency=/var/tmp/portage/dev-util/maturin-0.10.6/work/maturin-0.10.6/target/release/deps --cap-lints allow` (exit status: 134) warning: build failed, waiting for other jobs to finish... ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.1_desktop_plasma-j3-20210630-101334 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-11.1.0 * /usr/lib/llvm/12 12.0.0 Python 3.9.6 Available Ruby profiles: [1] ruby26 (with Rubygems) [2] ruby30 (with Rubygems) * Available Rust versions: [1] rust-bin-1.53.0 * The following VMs are available for generation-2: 1) IcedTea JDK 3.19.0 [icedtea-8] *) AdoptOpenJDK 8.292_p10 [openjdk-bin-8] Available Java Virtual Machines: [1] icedtea-8 [2] openjdk-bin-8 system-vm The Glorious Glasgow Haskell Compilation System, version 8.10.4 [1] php7.3 [2] php7.4 [3] php8.0 * HEAD of ::gentoo commit 5b0558f2e417f0ff29f2fe47a1b783ba6da24f9c Author: Repository mirror & CI <repomirrorci@gentoo.org> Date: Fri Jul 2 12:36:36 2021 +0000 2021-07-02 12:36:32 UTC emerge -qpvO dev-util/maturin [ebuild N ] dev-util/maturin-0.10.6 USE="-debug -test"
Created attachment 721053 [details] emerge-info.txt
Created attachment 721056 [details] dev-util:maturin-0.10.6:20210702-145243.log
Created attachment 721059 [details] emerge-history.txt
Created attachment 721062 [details] environment
Created attachment 721065 [details] etc.portage.tar.bz2
Created attachment 721068 [details] temp.tar.bz2
just like in https://bugs.gentoo.org/796164 but this time without codegen-units as I can see. not specifying codegen-units means it uses 16. is that failure repeatable for you without specifying codegen-units? does it faill all the time or randomly? can you try with RUSTFLAGS="-C codegen-units=1"
looks like the error comes not from rust, but from libc+kernel. just some context with explanations: https://lore.kernel.org/lkml/158955700764.647498.18025770126733698386.stgit@buzz/T/ https://github.com/bminor/glibc/blob/e8d52b64a54ba9ed7778ca9ce1f084eb5808f8d1/sysdeps/nptl/futex-internal.h#L82 /* Calls __libc_fatal with an error message. Convenience function for concrete implementations of the futex interface. */ static __always_inline __attribute__ ((__noreturn__)) void futex_fatal_error (void) { __libc_fatal ("The futex facility returned an unexpected error code.\n"); } static __always_inline int futex_wait (unsigned int *futex_word, unsigned int expected, int private) { int err = lll_futex_timed_wait (futex_word, expected, NULL, private); switch (err) { case 0: case -EAGAIN: case -EINTR: return -err; case -ETIMEDOUT: /* Cannot have happened as we provided no timeout. */ case -EFAULT: /* Must have been caused by a glibc or application bug. */ case -EINVAL: /* Either due to wrong alignment or due to the timeout not being normalized. Must have been caused by a glibc or application bug. */ case -ENOSYS: /* Must have been caused by a glibc bug. */ /* No other errors are documented at this time. */ default: futex_fatal_error (); } } so something returning default case error, which is unknown to futex_wait() I can't really reproduce this though.
@toralf, could you post the following info, second one preferably taken while builds are running, especially something rusty. zgrep HUGEPAGE /proc/config.gz grep -i huge /proc/meminfo
(In reply to Georgy Yakovlev from comment #9) > @toralf, could you post the following info, second one preferably taken > while builds are running, especially something rusty. > > > zgrep HUGEPAGE /proc/config.gz > > grep -i huge /proc/meminfo mr-fox ~ # zgrep HUGEPAGE /proc/config.gz CONFIG_ARCH_ENABLE_HUGEPAGE_MIGRATION=y CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD=y CONFIG_TRANSPARENT_HUGEPAGE=y # CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS is not set CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y the other command will take time
tinderbox@mr-fox ~ $ grep -i huge /proc/meminfo AnonHugePages: 0 kB ShmemHugePages: 0 kB FileHugePages: 0 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB Hugetlb: 0 kB
Are these still randomly happening? (I hope not) I'll close for now either way, hopefully not happening with the current version and toolchain.
