Blocking client hangs

[mcarpenter]

I'm seeing sporadic hangs after making a call to the get() and send() methods of the blocking client in reqwest 0.10.0. This happens every few runs of my short test case below (you might need a small shell loop to see the error).

Conditions:

• Ubuntu 18.04.3, 4.15.0-72-generic, x86_64
• rustc 1.40.0 (73528e339 2019-12-16), installed via rustup
• reqwest = { version = "0.10.0", features = ["blocking"] }
• Either HTTP or HTTPS (example.com doest not redirect HTTP->HTTPS).

The calls to get() and send() complete, and I can show the response, but the program hangs in a futex(2) call right after that. This seems like some sort of race and I'm not certain that the problem is in reqwest but I don't have a lot going on:

use reqwest;

fn main() {
    let url = "http://example.com";
    let client = reqwest::blocking::Client::new();
    match client.get(url).send() {
        Ok(response) => println!("Ok: {:?}", response), 
        Err(error)   => println!("Err: {:?}", error) 
    }
    println!("End")
} 

"End" is printed when the program hangs but main() does not return.

Output from strace(1) looks identical in both successful and hanging cases, except that a FUTEX_WAIT never returns in the hanging case. Here is the tail of that output for the hanging case (terminated with SIGINT):

futex(0x55de6584d99c, FUTEX_WAIT_PRIVATE, 0, {tv_sec=29, tv_nsec=999985900}) = 0
futex(0x55de6584d920, FUTEX_WAKE_PRIVATE, 1) = 0
write(1, "Ok: Response { url: \"http://exam"..., 418) = 418
write(5, "\1", 1)                       = 1
futex(0x7fc7def849d0, FUTEX_WAIT, 5723, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
strace: Process 5722 detached

Note that there are two futexes here: the first (30s timeout) is from the Default implementation of Timeout in blocking/client.rs. This seems okay. The second (hanging) mutex address appears earlier in the strace(1) output:

clone(child_stack=0x7fc7def83db0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7fc7def849d0, tls=0x7fc7def84700, child_tidptr=0x7fc7def849d0) = 5723

I'm not sure where this is coming from. Hints on how to progress debugging this would be appreciated. Thanks!

[seanmonstar]

Likely related to #746

[manfredlotz]

I have the same problem with an existing program which I upgraded to

reqwest = { version = "0.10", features = ["gzip", "blocking"] }

[seanmonstar]

Yea, closing as dupe of #746. Still investigating there.

[mcarpenter]

Confirm this was solved by #746's resolution (update to Tokio 0.2.8). Thanks!

[manfredlotz]

After having updated my program to use tokio 0.2.8 things are working fine again. Thanks to all who were involved in resolving the issue.