broken pipe error on OSX and ubuntu
ashleygwilliams opened this issue · 5 comments
running https://github.com/ashleygwilliams/npm-registry-follower-rust/tree/log on both OSX and Ubuntu i get:
Finished debug [unoptimized + debuginfo] target(s) in 0.0 secs
Running `target/debug/npm-registry-follower`
ERROR:tokio_proto::streaming::pipeline::client: pipeline error: No error.
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Io(Error { repr: Custom(Custom { kind: BrokenPipe, error: StringError("broken pipe") }) })', ../src/libcore/result.rs:799
note: Run with `RUST_BACKTRACE=1` for a backtrace.
error: Process didn't exit successfully: `target/debug/npm-registry-follower` (exit code: 101)
previously only got this error on https in OSX, now it is for all https on OSX and Ubuntu. have been speaking with @alexcrichton - he told me to file here. full log text for RUST_LOG=hyper,tokio_proto cargo run &> log.txt is at https://github.com/ashleygwilliams/npm-registry-follower-rust/blob/log/log.txt
EDIT: the log included is from being run on OSX. lemme know if you want the one from ubuntu and i can push that as well
And when on linux, I see an "unexpected EOF observed" instead of ""No error.", and I see that in the openssl lib https://github.com/sfackler/rust-openssl/blob/v0.9.3/openssl/src/ssl/mod.rs#L1567
Definitely seems bad! My hope is that the actual bug is somewhere in rust-openssl and rust-security-framework. Layers like native-tls and tokio-tls in theory are very thin and shouldn't introduce much of an opportunity for a bug, but this seems like as good a place as any to discuss what's going on regardless.
But ok, digging into the Linux failure first. (cc @sfackler). Looks like openssl return 0 from SSL_write, and hits the block @seanmonstar highlighted. From a strace it appears that sendto was called successfully prior, and otherwise no other syscall failed except for a read that returned "would block". Yet the block highlighted is when openssl returns SSL_ERROR_SYSCALL, so I'm a little confused about that.
Still trying to figure out what's going on.
Ok, I think the linux case was just busted on that condition -- sfackler/rust-openssl#539. Let's see what happens there. Now for osx!
Ok we've tracked this all back to a zero-length write coming from hyper, which neither the openssl crate or the security-framework crate handled that well. Both crates will need to get fixed, but in the meantime @seanmonstar's updated hyper to not do a zero-length write, so everything should be fixed!
❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️
thank you all so much for your efforts on this
❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️ ❤️