Segmentation fault on macOS

[logaritmisk]

Hi and thanks for an awesome crate!

With the latest version of hyper (0.12.0) I get a strange crash with this simple example code.

extern crate futures;
extern crate hyper;

use futures::Future;
use hyper::service::service_fn;
use hyper::{Client, Server};

fn main() {
    let addr = ([0, 0, 0, 0], 3000).into();

    let client = Client::new();

    let new_svc = move || {
        let client = client.clone();

        service_fn(move |_| client.get("http://www.w6rz.net/newmobcal1920.ts".parse().unwrap()))
    };

    let server = Server::bind(&addr)
        .serve(new_svc)
        .map_err(|e| eprintln!("server error: {}", e));

    hyper::rt::run(server);
}

Everything compiles, but when I try to call the server with:

$ curl -v 'localhost:3000' > /dev/null

It crashes.

This is the details I get: https://gist.github.com/logaritmisk/22d5202559e1d1c52e4f69d6ce4e4262

Strange thing is that it works when I don't compile with the release profile or if I use the current nightly.

I think this is the commit that "broke" my example.

It works on:

• stable - debug
• beta - debug
• nightly - release

Versions of rustc:

• rustc 1.26.1 (827013a31 2018-05-25)
• rustc 1.27.0-beta.8 (fe75e4464 2018-05-26)
• rustc 1.28.0-nightly (4ecf12bf0 2018-06-02)

Let me know if you want more information of if there is something I should test :)

[seanmonstar]

Hm, that code isn't doing anything unsafe...

@carllerche possibly a threadpool bug?

[sfackler]

Are you using an old version of OSX? There's a bug in some versions of the linker which can cause crashes when interacting with thread locals: rust-lang/rust#50586

[logaritmisk]

@sfackler I'm running 10.12.6

I tried it on another computer running 10.13.4 and that worked. Then I tested with lto = true on my older computer and that worked as well! So it seems it's the same issue as rust-lang/rust#50586

Thanks, now I have a workaround and can continue with my project 👍

Edit: Hmm, but now I get another issue. With lto = true and compiled with release on macOS 10.12.6, the code from my first post is using 200% of my CPU, and I can't call my endpoint.

[logaritmisk]

Okey, so I found a way to get this to work on 10.12.6.

Add #[inline] for the check method and compile with lto = false.

[carllerche]

Well, I would still like to figure out if it is a bug in Tokio or not.

It sounds like it is not a Tokio bug, but I'm not sure what the best way to confirm this would be.

[seanmonstar]

I, uh... wat? If this happens with thread locals, shouldn't it also occur often with the futures crate accessing the current task, and in Tokio accessing the current reactor and timer and stuff?

Sorry for the false alarm about the Tokio threadpool.

[seanmonstar]

So, can I just close this as a bug in macOS?