SIGSEGV on stable-x86_64-unknown-linux-musl in a few cargo tools

[kolbma]

I have installed stable-x86_64-unknown-linux-musl with rustup on Alpine Linux 3.15.

After successful installing a bunch of cargo tools, many of them do SIGSEGV:

• cargo-audit SIGSEGV on stable-x86_64-unknown-linux-musl rustsec/rustsec#504
• cargo-oudated SIGSEGV on stable-x86_64-unknown-linux-musl kbknapp/cargo-outdated#305
• cargo-duplicates SIGSEGV on stable-x86_64-unknown-linux-musl Keruspe/cargo-duplicates#5
• cargo-update SIGSEGV on stable-x86_64-unknown-linux-musl nabijaczleweli/cargo-update#171

But cargo cache, cargo license and cargo install, rustc and other stuff runs.

Not sure where the origin of the problem is.

[nabijaczleweli]

Cross-poosting my c-u comment:

The strace points to openssl, which is provided by FFI. If you bump your ulimit -c and get the backtrace with a debugger you'll probably be able to confirm that.

[kolbma]

Reading symbols from /home/rocket/.cargo/bin/cargo-outdated...
(gdb) r
Starting program: /home/rocket/.cargo/bin/cargo-outdated 
warning: Error disabling address space randomization: Operation not permitted

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x00007f673b6e43a0 in ossl_init ()
#2  0x00007f673b6b8db6 in curl_global_init ()
#3  0x00007f673b4b45ca in std::sync::once::Once::call_once::{{closure}} ()
#4  0x00007f673b1e64f8 in std::sync::once::Once::call_inner () at library/std/src/sync/once.rs:419
#5  0x00007f673b1e81af in curl::INIT_CTOR::init_ctor ()
#6  0x00007f673b72c7f8 in libc_start_init () at ../src_musl/src/env/__libc_start_main.c:64
#7  0x00007f673b72c81d in libc_start_main_stage2 () at ../src_musl/src/env/__libc_start_main.c:91
#8  0x00007f673b1e81ca in _start ()
(gdb)

Is this from here: https://github.com/sfackler/rust-openssl ?

[nabijaczleweli]

curl_global_init(3) is from libcurl, used by curl – ossl_init() is an internal initialiser in libcurl: https://github.com/curl/curl/blob/3a6b9231703268331793df95bd9c14e76f4e5653/lib/vtls/openssl.c#L1194

It seems to be called as

            assert_eq!(curl_sys::curl_global_init(curl_sys::CURL_GLOBAL_ALL), 0);

so as a bisect if it's something wrong with the rustc bindings/memory model/whatever or if it's your libcurl, try building/running:

int main() {
    printf("%d\n", curl_global_init(3L));
}

linked to the libcurl used by the curl crate – in the default configuration that's your global pkg-config libcurl (but may be in the target/ directory if curl-sys built its own).

[kolbma]

I've tried this

sfackler/rust-openssl#1462 (comment)

The variant with RUSTFLAGS="-Ctarget-feature=-crt-static"
And works then.

But according to rust-lang/compiler-team#422
this should be the default???

[nagisa]

No, -crt-static work has not been completed yet, as far as I know. The linked issue is just a proposal to make such change which has been accepted, but not necessarily implemented yet.

[polarathene]

Today these cargo tools build fine in a rust:alpine Docker image. The issue can be closed?

They will fail initially until the needed dependencies have been installed (eg: musl-dev + openssl-dev + openssl-libs-static) for the default +crt-static used by x86_64-unknown-linux-musl target in the container.

---

It seems that the problem originally was resolved Oct 2023 with Rust 1.72: #82912

Analysis of the backtrace showed a call to address 0. The issue was speculated and later reproduced on Twitter as Rust's link process emitting DT_NEEDED references to dynamic libraries in a static linked program (where symbolic runtime relocations are never processed and thereby end up evaluating to 0).

If targeting a static binary, the linker should never be instructed to search dynamic libraries; it should only link static ones, and fail to link if they are not present.

Static builds had a bug where unspecified link kind would default to dynamic linking: #111698

Previously, #[link] without an explicit kind = "static" would confuse the linker and end up producing a dynamically linked library because of the -Bdynamic flag.
However this binary would not work correctly anyways since it was linked with startup code for a static binary.