rust @1.71.1: buildbot failures for 10.9/10.10: thread 'main' has overflowed its stack

[mascguy (Christopher Nielsen)]

The only obvious failure in the buildbot logs, occurs at very end.

Unfortunately, there doesn't appear (?) to be any other detail, apart from the following nebulous error:

Finished dev [unoptimized] target(s) in 1m 20s

thread 'main' has overflowed its stack
fatal runtime error: stack overflow

​https://ports.macports.org/port/rust/builds/

[mascguy (Christopher Nielsen)]

Just curious... is this fixable simply by setting RUST_MIN_STACK to a reasonably large value, when invoking cargo?

RUST_MIN_STACK=104857600 cargo ...

[badger200]

On macOS 10.9 lldb reveals for /opt/local/var/macports/build/_opt_local_var_macports_sources_ema.uk.rsync.macports.org_macports_release_tarballs_ports_lang_rust/rust/work/rustc-1.71.1-src/build/bootstrap/debug/bootstrap :

Process 82233 stopped
* thread #1: tid = 0x122e197, 0x000000010035bcae bootstrap`_$LT$bootstrap..flags..Subcommand$u20$as$u20$clap_builder..derive..Subcommand$GT$::augment_subcommands::h1c27fa5c9b24b0e4 + 30 at flags.rs:203, name = 'main', queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x7fff5fb804a8)
    frame #0: 0x000000010035bcae bootstrap`_$LT$bootstrap..flags..Subcommand$u20$as$u20$clap_builder..derive..Subcommand$GT$::augment_subcommands::h1c27fa5c9b24b0e4 + 30 at flags.rs:203
   200      }
   201  }
   202  
-> 203  #[derive(Debug, Clone, Default, clap::Subcommand)]
   204  pub enum Subcommand {
   205      #[clap(aliases = ["b"], long_about = "\n
   206      Arguments:
(lldb)

[mascguy (Christopher Nielsen)]

Has duplicate issue:68151

[mascguy (Christopher Nielsen)]

Has duplicate issue:68177

[mascguy (Christopher Nielsen)]

Marcus, it looks like this is still occurring, even with today's update to a newer Rust release:

• ​https://build.macports.org/builders/ports-10.9_x86_64-builder/builds/269507/steps/install-port/logs/stdio
• ​https://build.macports.org/builders/ports-10.10_x86_64-builder/builds/262359/steps/install-port/logs/stdio

Is the following feasible, or do we need to look somewhere else...? (And no worries if you're already looking at all of this.)

Just curious... is this fixable simply by setting RUST_MIN_STACK to a reasonably large value, when invoking cargo?

RUST_MIN_STACK=104857600 cargo ...

[mqudsi (Mahmoud Al-Qudsi)]

Assuming that port doesn't unset environment variables, running sudo port install rust with a universally set RUST_MIN_STACK environment variable set to 104857600 does not work around this issue.

:info:build Executing:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_rust/rust/work/rustc-1.77.1-src" && /usr/bin/make -j8 -w all BOOTSTRAP_ARGS="-j8"
:debug:build system:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_rust/rust/work/rustc-1.77.1-src" && /usr/bin/make -j8 -w all BOOTSTRAP_ARGS="-j8"
:info:build make: Entering directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_rust/rust/work/rustc-1.77.1-src'
:info:build Building bootstrap
:info:build     Finished dev [unoptimized] target(s) in 0.66s
:info:build thread 'main' has overflowed its stack

[ryandesign (Ryan Carsten Schmidt)]

Replying to mqudsi:

Assuming that port doesn't unset environment variables,

MacPorts intentionally does not pass through your shell environment variables.

[mqudsi (Mahmoud Al-Qudsi)]

Replying to ryandesign:

MacPorts intentionally does not pass through your shell environment variables.

Ok, what's the easiest way to test out setting the RUST_MIN_STACK environment variable here?

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Using ​git bisect, it seems this error starts at commit ​32e27cc60765ae21426b31073ba9ac2bda499c8d.
I do not know why this only affect 10.10, 10.9, and 10.5.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

There is a ​pull request to fix this problem.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

In 6e59675459bc6f396b586da4acccd60a94f9ba5a/macports-legacy-support (master):

provide workaround for pthread_get_stacksize_np

see ​https://github.com/rust-lang/rust/issues/43347
fixes #68015

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

In 34e47c0a3bafc1693ce83d24f03264ba05cb7c86/macports-legacy-support (master):

add test for bug in pthread_get_stacksize_np

see ​https://github.com/rust-lang/rust/issues/43347
see #68015

[jmroot (Joshua Root)]

Replying to mqudsi:

Replying to ryandesign:

MacPorts intentionally does not pass through your shell environment variables.

Ok, what's the easiest way to test out setting the RUST_MIN_STACK environment variable here?

I know the issue has been fixed already, but for reference, you would do this by editing the Portfile and appending to build.env.

[mqudsi (Mahmoud Al-Qudsi)]

Thanks, @jmroot. I'll file that away for the future.

---

I'm sorry if I'm asking a stupid question, but I tried to test this just now on macOS 10.10 and immediately ran into a problem: it seems none of the mirrors have a rust rust-1.77.1_0.darwin_14.x86_64.tbz2 (specifically, darwin_14 in there) available for download.

Checking manually, it seems darwin_10 through darwin_23 are all present with the exception of darwin_13 and darwin_14. Is this a separate issue, is it just a matter of time until the build bots do their thing, or is there something else I need to look into?

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Replying to mqudsi:

I'm sorry if I'm asking a stupid question, but I tried to test this just now on macOS 10.10 and immediately ran into a problem: it seems none of the mirrors have a rust rust-1.77.1_0.darwin_14.x86_64.tbz2 (specifically, darwin_14 in there) available for download.

Checking manually, it seems darwin_10 through darwin_23 are all present with the exception of darwin_13 and darwin_14. Is this a separate issue, is it just a matter of time until the build bots do their thing, or is there something else I need to look into?

The issue is "fixed" but is only available in the ​development ecosystem.
The ​policy of the legacy-support is to "allow a bit of time" before releasing development versions as versioned releases.
Once that happens, ​Rust can be updated.
After that, the buildbots should build the new version of Rust.
Sorry for the confusion.

[mqudsi (Mahmoud Al-Qudsi)]

Replying to MarcusCalhoun-Lopez:

The issue is "fixed" but is only available in the ​development ecosystem.
The ​policy of legacy-support is to "allow a bit of time" before releasing development versions as versioned releases.
Once that happens, ​Rust can be updated.
After that, the buildbots should build the new version of Rust.
Sorry for the confusion.

No worries; thanks for taking the time to explain that!