Bug 799878 – dev-util/maturin-0.10.6 - error: could not compile serde_json

• Product: Gentoo Linux
• Status: RESOLVED WORKSFORME

[Description Toralf Förster 2021-07-02 15:29:47 UTC]

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 <[e-mail]>
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"

[Comment 1 Toralf Förster 2021-07-02 15:29:48 UTC]

Created attachment 721053 [details]
emerge-info.txt

[Comment 2 Toralf Förster 2021-07-02 15:29:49 UTC]

Created attachment 721056 [details]
dev-util:maturin-0.10.6:20210702-145243.log

[Comment 3 Toralf Förster 2021-07-02 15:29:51 UTC]

Created attachment 721059 [details]
emerge-history.txt

[Comment 4 Toralf Förster 2021-07-02 15:29:52 UTC]

Created attachment 721062 [details]
environment

[Comment 5 Toralf Förster 2021-07-02 15:29:53 UTC]

Created attachment 721065 [details]
etc.portage.tar.bz2

[Comment 6 Toralf Förster 2021-07-02 15:29:55 UTC]

Created attachment 721068 [details]
temp.tar.bz2

[Comment 7 Georgy Yakovlev 2021-07-02 20:35:48 UTC]

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"

[Comment 8 Georgy Yakovlev 2021-07-02 21:19:17 UTC]

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.

[Comment 9 Georgy Yakovlev 2021-07-09 23:19:58 UTC]

@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

[Comment 10 Toralf Förster 2021-07-10 08:13:23 UTC]

(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

[Comment 11 Toralf Förster 2021-07-10 08:37:38 UTC]

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

[Comment 12 Ionen Wolkens 2021-10-15 15:57:35 UTC]

Are these still randomly happening? (I hope not)

I'll close for now either way, hopefully not happening with the current version and toolchain.