Segfault when running in Alpine

[fredrik-jansson-se]

Hi,

I'm trying to use rusoto_ec2 in an alpine Docker image, but run into a segfault that seems to originate in native_tls.

Please let me know if there is anything I can provide to shed some more light on this issue.

I've added the code here: https://github.com/fredrik-jansson-se/tls-segfault

I reproduce by this:

docker build -t aws . 
./run-docker.sh
/ # /usr/local/cargo/bin/native-tls-segfault
Segmentation fault (core dumped)

Thread 1 "native-tls-segf" received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x00007f637322277e in native_tls::imp::TlsConnector::new ()
#2  0x00007f6373222ee3 in native_tls::TlsConnector::new ()
#3  0x00007f637317c7d3 in hyper_tls::client::HttpsConnector<hyper::client::connect::http::HttpConnector>::new ()
#4  0x00007f6372f3af1a in rusoto_core::request::HttpClient::new ()
#5  0x00007f6372f456d2 in rusoto_core::client::Client::shared ()
#6  0x00007f6372f06450 in rusoto_ec2::generated::Ec2Client::new ()
#7  0x00007f6372efe3c1 in <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll ()
#8  0x00007f6372f03a1d in tokio::runtime::enter::Enter::block_on ()
#9  0x00007f6372efcd06 in tokio::runtime::thread_pool::ThreadPool::block_on ()
#10 0x00007f6372efe196 in tokio::runtime::context::enter ()
#11 0x00007f6372efce99 in tokio::runtime::handle::Handle::enter ()
#12 0x00007f6372eff337 in native_tls_segfault::main ()
#13 0x00007f6372efcf63 in std::sys_common::backtrace::__rust_begin_short_backtrace ()
#14 0x00007f6372efcf79 in std::rt::lang_start::{{closure}} ()
#15 0x00007f6373242068 in core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once ()
    at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/core/src/ops/function.rs:259
#16 std::panicking::try::do_call () at library/std/src/panicking.rs:373
#17 std::panicking::try () at library/std/src/panicking.rs:337
#18 std::panic::catch_unwind () at library/std/src/panic.rs:379
#19 std::rt::lang_start_internal () at library/std/src/rt.rs:51
#20 0x00007f6372eff442 in main ()

[fredrik-jansson-se]

Could be reproduced w/o tokio and rusoto.

(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x00007feec771380e in native_tls::imp::TlsConnector::new ()
#2  0x00007feec7713573 in native_tls::TlsConnector::new ()
#3  0x00007feec7713254 in native_tls_segfault::main ()
#4  0x00007feec77131d3 in std::sys_common::backtrace::__rust_begin_short_backtrace ()
#5  0x00007feec77131e9 in std::rt::lang_start::{{closure}} ()
#6  0x00007feec772a618 in core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once ()
    at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/core/src/ops/function.rs:259
#7  std::panicking::try::do_call () at library/std/src/panicking.rs:373
#8  std::panicking::try () at library/std/src/panicking.rs:337
#9  std::panic::catch_unwind () at library/std/src/panic.rs:379
#10 std::rt::lang_start_internal () at library/std/src/rt.rs:51
#11 0x00007feec7713402 in main ()

[sfackler]

Alpine libraries link dynamically to musl libc, while rustc statically links to it by default. The conflict there somehow causes the libssl dynamic library to not link in properly at runtime. If you set RUSTFLAGS=-Ctarget-feature=-crt-static to configure rustc to dynamically link to musl as well, things appear to work.

If you want a fully statically linked binary, you'll need to build openssl from source configured to statically link to musl as well. You can enable the vendored Cargo feature to have that happen automatically for you.

[fredrik-jansson-se]

Awesome, that worked perfectly, thank you!!

[jplatte]

Just ran into this as well, could this maybe be noted in README.md?