SIGSEGV with program linked against OpenSSL in an Alpine container

I have a program that uses the openssl crate (via reqwest). I was building and running it in a Docker container based on Alpine, and found that it would exit with status 139 (indicating SIGSEGV) when setting up the OpenSSL methods. I've put together a minimal reproduction case at


As you can see from the Dockerfile, if I build on Buster, or if I build statically on Alpine, things work fine. So clearly there is some problem with loading the dynamic library in the Alpine image. How do I debug this further?

I've confirmed that, inside the Alpine container, libssl does exist and the binary is configured to link it:

# ldd target/debug/openssl-crash
        /lib/ (0x7faca41c3000) => /lib/ (0x7faca40e8000) => /lib/ (0x7faca3e69000)
 # ls -l  /lib/
-rwxr-xr-x    1 root     root        523728 Apr 21  2020 /lib/

I see you're already installing gdb. So you just need to run it with gdb and look at the stack trace.

Ah, sorry, I forgot to include the stack trace! It looks like the relevant function's address is just set to zeroes, but I don't understand why.

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x00007f62eaa764aa in openssl::ssl::SslMethod::tls ()
    at /usr/local/cargo/registry/src/
#2  0x00007f62eaa7625a in openssl_crash::main () at src/

The x86_64-unknown-linux-musl target statically links to MUSL by default, but Alpine uses a dynamically linked MUSL. Since you're dynamically linking to Alpine's OpenSSL, you're ending up with 2 MUSLs and then things explode from there. You can pass RUSTFLAGS=-C target-feature=-crt-static to have rustc dynamically link to Alpine's MUSL, or build an OpenSSL that also statically links to MUSL (e.g. with openssl's vendored Cargo feature).


This worked beautifully, thank you.