Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Latest cargo nightly instantly segfaults on FreeBSD in Cirrus CI #15092

Open
asomers opened this issue Jan 23, 2025 · 3 comments
Open

Latest cargo nightly instantly segfaults on FreeBSD in Cirrus CI #15092

asomers opened this issue Jan 23, 2025 · 3 comments
Labels
C-bug Category: bug O-freebsd OS: FreeBSD S-needs-info Status: Needs more info, such as a reproduction or more background for a feature request.

Comments

@asomers
Copy link

asomers commented Jan 23, 2025

Problem

The latest nightly cargo instantly segfaults when run on FreeBSD in Cirrus CI. It doesn't even need to attempt a build. Simply cargo -h will segfault. I haven't managed to reproduce this in a local VM, so I don't know what's special about Cirrus CI. But the failures only began to happen within the last 24 hours.

Steps

In a FreeBSD 14.0 or 14.1 (other versions are untested) instance on Cirrus CI, install Rust and invoke Cargo like this:

$ fetch https://sh.rustup.rs -o rustup.sh
$ sh rustup.sh -y --profile=minimal --default-toolchain nightly-x86_64-unknown-freebsd
$ . $HOME/.cargo/env
$ cargo -h
Segmentation fault (core dumped)

Possible Solution(s)

No response

Notes

Here is the stack backtrace from gdb.

Starting program: /tmp/.cargo/bin/cargo -h
process 13657 is executing new program: /tmp/.rustup/toolchains/nightly-x86_64-unknown-freebsd/bin/cargo

Program received signal SIGSEGV, Segmentation fault.
Address not mapped to object.
libunwind::CFI_Parser<libunwind::LocalAddressSpace>::parseCIE (addressSpace=..., cie=18446744073502207747, 
    cieInfo=0x7fffffffa480) at /usr/src/contrib/llvm-project/libunwind/src/DwarfParser.hpp:332
332       pint_t cieLength = (pint_t)addressSpace.get32(p);
(gdb) bt
#0  libunwind::CFI_Parser<libunwind::LocalAddressSpace>::parseCIE (addressSpace=..., cie=18446744073502207747, 
    cieInfo=0x7fffffffa480) at /usr/src/contrib/llvm-project/libunwind/src/DwarfParser.hpp:332
#1  0x0000000802b9ae8c in libunwind::CFI_Parser<libunwind::LocalAddressSpace>::findFDE (addressSpace=..., 
    pc=pc@entry=19247820, ehSectionStart=42259904, sectionLength=<optimized out>, fdeHint=fdeHint@entry=0, 
    fdeInfo=fdeInfo@entry=0x7fffffffa4b8, cieInfo=0x7fffffffa480)
    at /usr/src/contrib/llvm-project/libunwind/src/DwarfParser.hpp:264
#2  0x0000000802b9ab22 in libunwind::UnwindCursor<libunwind::LocalAddressSpace, libunwind::Registers_x86_64>::getInfoFromDwarfSection (this=this@entry=0x7fffffffab00, pc=pc@entry=19247820, sects=..., 
    fdeSectionOffsetHint=fdeSectionOffsetHint@entry=0)
    at /usr/src/contrib/llvm-project/libunwind/src/UnwindCursor.hpp:1689
#3  0x0000000802b97fe0 in libunwind::UnwindCursor<libunwind::LocalAddressSpace, libunwind::Registers_x86_64>::setInfoBasedOnIPRegister (this=0x7fffffffab00, isReturnAddress=true)
    at /usr/src/contrib/llvm-project/libunwind/src/UnwindCursor.hpp:2634
#4  0x0000000802b97e32 in libunwind::UnwindCursor<libunwind::LocalAddressSpace, libunwind::Registers_x86_64>::step (
    this=0x7fffffffab00, stage2=<optimized out>) at /usr/src/contrib/llvm-project/libunwind/src/UnwindCursor.hpp:2946
#5  0x0000000802b95379 in _Unwind_Backtrace (
    callback=0x25ac480 <std::backtrace_rs::backtrace::libunwind::trace::trace_fn>, ref=0x7fffffffaca8)
    at /usr/src/contrib/llvm-project/libunwind/src/UnwindLevel1-gcc-ext.c:156
#6  0x0000000002592725 in std::backtrace_rs::backtrace::libunwind::trace ()
    at library/std/src/../../backtrace/src/backtrace/libunwind.rs:116
#7  std::backtrace_rs::backtrace::trace_unsynchronized<std::backtrace::{impl#4}::create::{closure_env#0}> ()
    at library/std/src/../../backtrace/src/backtrace/mod.rs:66
#8  std::backtrace::Backtrace::create () at library/std/src/backtrace.rs:331
#9  0x0000000002592590 in std::backtrace::Backtrace::capture () at library/std/src/backtrace.rs:296
#10 0x000000000123b2f8 in <anyhow::Error as core::convert::From<clap_builder::error::Error>>::from ()
#11 0x0000000001a30856 in <cargo::util::errors::CliError as core::convert::From<clap_builder::error::Error>>::from ()
#12 0x0000000001327f67 in cargo::cli::main ()
#13 0x00000000012ff725 in cargo::main ()
#14 0x00000000012e4463 in std::sys::backtrace::__rust_begin_short_backtrace::<fn(), ()> ()
#15 0x000000000132fb29 in std::rt::lang_start::<()>::{closure#0} ()
#16 0x0000000002591230 in core::ops::function::impls::{impl#2}::call_once<(), (dyn core::ops::function::Fn<(), Output=i32>

And here are some links to recent builds demonstrating the problem:

Version

# cargo --version --verbose
cargo 1.86.0-nightly (045bf21b3 2025-01-17)
release: 1.86.0-nightly
commit-hash: 045bf21b36a2e1f3ed85e38278d1c3cc4305e134
commit-date: 2025-01-17
host: x86_64-unknown-freebsd
libgit2: 1.9.0 (sys:0.20.0 vendored)
libcurl: 8.9.0-DEV (sys:0.4.74+curl-8.9.0 vendored ssl:OpenSSL/1.1.1w)
ssl: OpenSSL 1.1.1w  11 Sep 2023
os: FreeBSD 14.1-RELEASE [64-bit]
@asomers asomers added C-bug Category: bug S-triage Status: This issue is waiting on initial triage. labels Jan 23, 2025
@weihanglo
Copy link
Member

But the failures only began to happen within the last 24 hours.

Nightly cargo hasn't changed since 2025-01-17, so if it worked one day ago it should generally work now.
To bisect which nightly start failing, is it possible to configure CI to download a specific nightly version? Like rustup install nightly-2024-01-22.

@weihanglo weihanglo added S-needs-info Status: Needs more info, such as a reproduction or more background for a feature request. O-freebsd OS: FreeBSD and removed S-triage Status: This issue is waiting on initial triage. labels Jan 23, 2025
@ehuss
Copy link
Contributor

ehuss commented Jan 23, 2025

FreeBSD builds were switched from 12 to 13 in rust-lang/rust#132232 about a day ago.

cc @asomers FYI

@asomers
Copy link
Author

asomers commented Jan 23, 2025

Using rustup, I've bisected the problem down. It happens with nightly-2025-01-23 but not nightly-2025-01-22. And it only happens when RUST_BACKTRACE=1 or RUST_BACKTRACE=full. So it's probably a regression of rust-lang/rust#132185 .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: bug O-freebsd OS: FreeBSD S-needs-info Status: Needs more info, such as a reproduction or more background for a feature request.
Projects
None yet
Development

No branches or pull requests

3 participants