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.

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.