segfault when running basic example on Alpine (musl)

[jlesage]

Initializing gtk seems to crash on Alpine Linux (which uses musl). The segmentation fault can be reproduced by running the basics example (or any other).

To reproduce, use an Alpine Docker container:

docker run --rm -ti alpine:3.14

Run the following commands to build examples:

apk --no-cache add build-base curl git bash gtk+3.0-dev
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | bash -s -- -y
source $HOME/.cargo/env
cd /tmp/
git clone https://github.com/gtk-rs/gtk3-rs.git
cd gtk3-rs/examples/
cargo build

And run the basics example:

export RUST_BACKTRACE=full
../target/debug/basics

You get the following crash:

Program terminated with signal SIGSEGV, Segmentation fault.

GDB backtrace from generate core:

#0  0x0000000000000000 in ?? ()
gtk-rs/gtk3-rs#1  0x00007f339858d155 in gtk::auto::application::Application::new (application_id=..., flags=...) at gtk/src/application.rs:18
gtk-rs/gtk3-rs#2  0x00007f33985899d7 in basics::main () at examples/basics/main.rs:20

[qarmin]

Looks that this may be really GTK or GTK-rs bug(strange that when I run similar commands a while ago, then it worked fine)

When running czkawka, then it crash in a little different place

#0  0x0000000000000000 in ?? ()
No symbol table info available.
gtk-rs/gtk3-rs#1  0x00007f02646ce0e9 in gtk::rt::init () at /root/.cargo/registry/src/github.com-1ecc6299db9ec823/gtk-0.14.3/src/rt.rs:119
        argv = alloc::vec::Vec<alloc::string::String, alloc::alloc::Global> {buf: alloc::raw_vec::RawVec<alloc::string::String, alloc::alloc::Global> {ptr: core::ptr::unique::Unique<alloc::string::String> {pointer: 0x5555563b91a0, _marker: core::marker::PhantomData<alloc::string::String>}, cap: 1, alloc: alloc::alloc::Global}, len: 1}
gtk-rs/gtk3-rs#2  0x00007f0263e0bb50 in czkawka_gui::main () at czkawka_gui/src/main.rs:87
        exit_program_after_initialization = false

which probably points at this line
https://github.com/gtk-rs/gtk3-rs/blob/bd5f76236a2fbcad6e97001f1d9230efad7eee74/gtk/src/rt.rs#L119

[sdroege]

Also any of the gtk-rs-core examples are segfaulting the same way.

[sdroege]

The problem seems to be related to no shared libraries having been loaded automatically at that point and instead all functions from shared libraries pointing to NULL.

$ gdb /tmp/gtk-rs-core/target/debug/gio_futures_await
(gdb) r
Starting program: /tmp/gtk-rs-core/target/debug/gio_futures_await 
warning: Error disabling address space randomization: Operation not permitted

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x00007ff5f3496dba in glib::auto::main_context::MainContext::default () at glib/src/auto/main_context.rs:107
#2  0x00007ff5f34828b5 in gio_futures_await::main () at examples/gio_futures_await/main.rs:9
(gdb) info sharedlibrary 
No shared libraries loaded at this time.

However it is linked to the corresponding shared libraries

$ ldd /tmp/gtk-rs-core/target/debug/gio_futures_await
	/lib/ld-musl-x86_64.so.1 (0x7f98cf664000)
	libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x7f98cf575000)
	libgio-2.0.so.0 => /usr/lib/libgio-2.0.so.0 (0x7f98cf3cc000)
	libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x7f98cf2c2000)
	libffi.so.7 => /usr/lib/libffi.so.7 (0x7f98cf2b7000)
	libc.musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x7f98cf664000)
	libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x7f98cf2b2000)
	libz.so.1 => /lib/libz.so.1 (0x7f98cf298000)
	libmount.so.1 => /lib/libmount.so.1 (0x7f98cf245000)
	libintl.so.8 => /usr/lib/libintl.so.8 (0x7f98cf238000)
	libpcre.so.1 => /usr/lib/libpcre.so.1 (0x7f98cf1dc000)
	libblkid.so.1 => /lib/libblkid.so.1 (0x7f98cf192000)

[sdroege]

This is some fallout from rust-lang/compiler-team#422 . If you build with RUSTFLAGS="-C target-feature=-crt-static" it will work fine, but there's not much we can do here really. See also the linked other issues at the bottom of that issue.

[Cogitri]

See rust-lang/rust#82912 for more info on this, TLDR things blow up when using a static musl version and dynamic libraries that are linked against a different dynamic musl. This may be fixed by rust in the future by using dynamic musl on musl systems.

[jlesage]

Thanks for the details!

Interestingly, when installing Rust from the Alpine repository, the crash cannot be reproduced. For example, when compiling with the official 1.56.1 version, the binaries crash, but when installing the same version from the Alpine repository, they don't crash. So it seems that they fixed Rust issues on their side.

See https://git.alpinelinux.org/aports/tree/community/rust?h=master

[Cogitri]

Yes, rust from Alpine’s repos is patched to use -crt-static by default.