SIGSEGV on generating debug info for `rhai`

[Cerber-Ursi]

I tried to build a project which depends on crate rhai. Building the dependency crashed rustc with SIGSEGV, with the following backtrace:

/home/cerber-ursi/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/librustc_driver-5aef5f09b8575cae.so(+0x2b51e36)[0x7fae28351e36]
/lib/x86_64-linux-gnu/libc.so.6(+0x42520)[0x7fae254f8520]
/home/cerber-ursi/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/libLLVM-17-rust-1.75.0-stable.so(_ZN4llvm7MDTuple7getImplERNS_11LLVMContextENS_8ArrayRefIPNS_8MetadataEEENS4_11StorageTypeEb+0x130c)[0x7fae2384355a]
/home/cerber-ursi/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/librustc_driver-5aef5f09b8575cae.so(_RNvXs2_NtCseOY8Nz2WDDU_18rustc_codegen_llvm9debuginfoNtNtB7_7context9CodegenCxNtNtNtCshXex1mlJAZ7_17rustc_codegen_ssa6traits9debuginfo16DebugInfoMethods23create_vtable_debuginfo+0x761)[0x7fae2a0d71a1]
/home/cerber-ursi/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/librustc_driver-5aef5f09b8575cae.so(+0x460ea46)[0x7fae29e0ea46]
/home/cerber-ursi/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/librustc_driver-5aef5f09b8575cae.so(+0x460e224)[0x7fae29e0e224]
/home/cerber-ursi/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/librustc_driver-5aef5f09b8575cae.so(+0x42db1f4)[0x7fae29adb1f4]
/home/cerber-ursi/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/librustc_driver-5aef5f09b8575cae.so(+0x46d0868)[0x7fae29ed0868]
/home/cerber-ursi/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/librustc_driver-5aef5f09b8575cae.so(+0x4abe320)[0x7fae2a2be320]
/home/cerber-ursi/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/librustc_driver-5aef5f09b8575cae.so(+0x4aac5d5)[0x7fae2a2ac5d5]
/home/cerber-ursi/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/librustc_driver-5aef5f09b8575cae.so(_RNvXs0_CseOY8Nz2WDDU_18rustc_codegen_llvmNtB5_18LlvmCodegenBackendNtNtNtCshXex1mlJAZ7_17rustc_codegen_ssa6traits7backend19ExtraBackendMethods20compile_codegen_unit+0x12e)[0x7fae2a2aa5cc]
/home/cerber-ursi/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/librustc_driver-5aef5f09b8575cae.so(_RNvXs5_CseOY8Nz2WDDU_18rustc_codegen_llvmNtB5_18LlvmCodegenBackendNtNtNtCshXex1mlJAZ7_17rustc_codegen_ssa6traits7backend14CodegenBackend13codegen_crate+0x7d1)[0x7fae2a3fbb51]
/home/cerber-ursi/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/librustc_driver-5aef5f09b8575cae.so(_RNvNtCslBK4JWoPbFM_15rustc_interface6passes13start_codegen+0x105)[0x7fae2a3f9b45]
/home/cerber-ursi/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/librustc_driver-5aef5f09b8575cae.so(_RNvMs3_NtCslBK4JWoPbFM_15rustc_interface7queriesNtB5_7Queries15ongoing_codegen+0x196)[0x7fae2a3f95e6]
/home/cerber-ursi/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/librustc_driver-5aef5f09b8575cae.so(+0x4c07071)[0x7fae2a407071]
/home/cerber-ursi/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/librustc_driver-5aef5f09b8575cae.so(+0x4c0215b)[0x7fae2a40215b]
/home/cerber-ursi/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/librustc_driver-5aef5f09b8575cae.so(+0x4c01fb3)[0x7fae2a401fb3]
/home/cerber-ursi/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/libstd-90f6ddbf82de36ec.so(rust_metadata_std_409886f6357001f0+0xb96a5)[0x7fae257986a5]
/lib/x86_64-linux-gnu/libc.so.6(+0x94ac3)[0x7fae2554aac3]
/lib/x86_64-linux-gnu/libc.so.6(+0x126850)[0x7fae255dc850]

This behavior is consistent from build to build, and cargo clean doesn't help either. I can't reproduce this on another machine though, so it's possible that something is corrupted at my side, but I don't know what could it ever be.

rustc --version --verbose:

rustc 1.75.0 (82e1608df 2023-12-21)
binary: rustc
commit-hash: 82e1608dfa6e0b5569232559e3d385fea5a93112
commit-date: 2023-12-21
host: x86_64-unknown-linux-gnu
release: 1.75.0
LLVM version: 17.0.6

Using release build or setting debug = false for dev one helps (since the whole problematic part of code seems to be skipped), but I'd like to report this anyway.

[Jules-Bertholet]

@rustbot label T-compiler A-debuginfo I-crash E-needs-bisection

[saethlin]

I tried to build a project which depends on crate rhai.

This information is not sufficient to reproduce the problem. I tried this:

cargo new --bin scratch
cd scratch
cargo add rhai
cargo +stable build

which uses all the information you've provided, and I do not get a crash.

Can you share the project that depends on rhai? Or if you really can't do that, can you share the part of your Cargo.lock that starts with

[[package]]
name = "rhai"

[Cerber-Ursi]

I've tried to minimize the project, but got the same exact segfault in different dependencies with different changes to my own code. Sometimes it's clap_lex or clap_builder, sometimes it's ahash, sometimes, if I remove too much, project actually compiles without error. Nevertheless, here's the minimal example I was able to come up with, which segfaults in rhai: https://github.com/Cerber-Ursi/rustc-dependency-segfault; if it doesn't help, I can share the whole project as it was created originally.

[saethlin]

I've build that repo several times with cargo +stable build and I have not seen a crash.

I can't reproduce this on another machine

Makes me think that there is a system-wide setting that's required to hit this bug. Often people stick such configurations in ~/.cargo/config, ~/.cargo/config.toml, or set environment variables in their shell startup files.

There are two ways to figure out if such a configuration is responsible; you can cargo build --verbose and pull out the line that contains --crate-name rhai, that will contain all the flags used for building that crate. If you paste that in here we can check if there's anything non-default and figure out how to match your flags.

You can also write a Dockerfile that reproduces the crash when built. That tends to be a bit harder.

[Cerber-Ursi]

Cargo reported the exact command on segfault, here it is:

/home/cerber-ursi/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/rustc \
    --crate-name rhai \
    --edition=2018 \
    /home/cerber-ursi/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rhai-1.16.3/src/lib.rs \
    --error-format=json \
    --json=diagnostic-rendered-ansi,artifacts,future-incompat \
    --diagnostic-width=183 \
    --crate-type lib \
    --emit=dep-info,metadata,link \
    -C embed-bitcode=no \
    -C debuginfo=2 \
    --cfg 'feature="default"' \
    --cfg 'feature="std"' \
    -C metadata=d9c0718163daded0 \
    -C extra-filename=-d9c0718163daded0 \
    --out-dir /home/cerber-ursi/repos/experimental/rustc-dependency-segfault/target/debug/deps \
    -L dependency=/home/cerber-ursi/repos/experimental/rustc-dependency-segfault/target/debug/deps \
    --extern ahash=/home/cerber-ursi/repos/experimental/rustc-dependency-segfault/target/debug/deps/libahash-1cfb9062e30af57c.rmeta \
    --extern bitflags=/home/cerber-ursi/repos/experimental/rustc-dependency-segfault/target/debug/deps/libbitflags-e909367b0b252463.rmeta \
    --extern num_traits=/home/cerber-ursi/repos/experimental/rustc-dependency-segfault/target/debug/deps/libnum_traits-021f0c8717b1cfd6.rmeta \
    --extern once_cell=/home/cerber-ursi/repos/experimental/rustc-dependency-segfault/target/debug/deps/libonce_cell-49ebd9646360b73f.rmeta \
    --extern rhai_codegen=/home/cerber-ursi/repos/experimental/rustc-dependency-segfault/target/debug/deps/librhai_codegen-57b3f42f04520476.so \
    --extern smallvec=/home/cerber-ursi/repos/experimental/rustc-dependency-segfault/target/debug/deps/libsmallvec-72b756aa5f266519.rmeta \
    --extern smartstring=/home/cerber-ursi/repos/experimental/rustc-dependency-segfault/target/debug/deps/libsmartstring-5ac2b2657f26d421.rmeta \
    --cap-lints allow

[Cerber-Ursi]

Reproduced it on cloned rhai repository directly, will try to minimize further.

[Cerber-Ursi]

Nope, no luck it seems. This commit as-is segfaults with cargo build reliably, but removing just anything (even tests or benchmarks) allows it to succeed. Not sure where to dig next, to be honest.

[saethlin]

Is the segfault backtrace always the same as the one in the issue description?

Can you reproduce the segfault by writing a Dockerfile that will trip the segfault when you docker build it?

[Cerber-Ursi]

Backtrace is always the same, yes. As for Docker - will try a bit later.