Body dropped too late when an h1 handshake hits an error
メンテナーはふだん 3 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 48/100
- issue の種類
- バグ
- 明瞭さ
- おおむね明確
- 活発さ
- 活発
- 技術スタック
- rust
- 領域
- api, networking
調査の方向性
提供された reproducer から始め、参照されている行の src/client/dispatch.rs を調査し、その後、h1 handshake error と channel shutdown が send_request とどのように相互作用するかを追跡します。connection と future が drop された後に request body が回収されるかを確認し、reproducer の assertion と "body wasn't dropped" が出力されないことを完了チェックとして使用します。
索引モデルが issue の本文から書いたものです。
説明
Version
hyper 1.10.1
Platform
Linux x86_64 7.0.0-27-generic
Summary
Wasmtime hit a spurious failure in a test recently in CI that I think I've diagnosed to some code in hyper. The test in question is a wasm guest that issues an HTTP/1.1 request to a server that only works with HTTP/2, and the expectation is that the wasm guest gets a HttpProtocolError within wasm. This test ended up timing out in CI and getting a timeout failure instead.
After some investigation it looks like this is due hyper's use of tokio's channels and the precise synchronization/sequencing of sending a request from one channel to another. The code in question attached here is a small program which showcases this race where the intention of the test is:
- No actual I/O is performed, it's just in-memory data structures.
- An http1 handshake is done against a connection that reads corrupt data (sort of mimicking what an http2 server might initiate with)
- The code in question sends a request, completes the connection I/O, and then asserts that the request was dropped.
- There's various bits and pieces of the program intended to stress scheduling to make the bug appear more often.
Code Sample
use bytes::Bytes;
use http_body::Body;
use hyper::rt::{Read, ReadBufCursor, Write};
use std::future::Future;
use std::io;
use std::pin::Pin;
use std::sync::atomic::{AtomicBool, Ordering};
use std::sync::{Arc, Barrier};
use std::task::{Context, Poll, Waker};
fn main() {
// start up some background work to stress scheduling a bit more.
for _ in 0..16 {
std::thread::spawn(|| loop {
std::hint::black_box(std::time::Instant::now());
});
}
let rt = tokio::runtime::Builder::new_current_thread()
.enable_all()
.build()
.unwrap();
let _guard = rt.enter();
for _ in 0..2_000_000 {
// Handshake against the mock IO. handshake() itself does no I/O.
let (mut sender, mut conn) = match rt
.block_on(hyper::client::conn::http1::handshake::<_, TrackedBody>(
MockIo::default(),
)) {
Ok(p) => p,
Err(_) => continue,
};
let dropped = Arc::new(AtomicBool::new(false));
let req = hyper::Request::connect("http://x/")
.body(TrackedBody {
dropped: dropped.clone(),
})
.unwrap();
let barrier = Arc::new(Barrier::new(2));
// Thread B: dispatch the request the instant the barrier releases.
let b2 = barrier.clone();
let sender_thread = std::thread::spawn(move || {
b2.wait();
let fut = sender.send_request(req);
(fut, sender)
});
barrier.wait();
let waker = Waker::noop();
let mut cx = Context::from_waker(&waker);
for _ in 0..4 {
if Pin::new(&mut conn).poll(&mut cx).is_ready() {
break;
}
}
drop(conn);
let (fut, sender2) = sender_thread.join().unwrap();
drop(fut);
// At this point the future from `send_request` is gone, the receiver
// through `conn` is gone, so it should be the case that our body in the
// request that was sent was dropped. However this isn't always true so
// sometimes this will print out.
if !dropped.load(Ordering::SeqCst) {
println!("body wasn't dropped");
}
drop(sender2);
assert!(
dropped.load(Ordering::SeqCst),
"request must be reclaimed once the SendRequest drops"
);
}
}
#[derive(Default)]
struct MockIo {
gave: bool,
}
impl Read for MockIo {
fn poll_read(
mut self: Pin<&mut Self>,
_cx: &mut Context<'_>,
mut buf: ReadBufCursor<'_>,
) -> Poll<io::Result<()>> {
// read enough bytes that the connection should terminate with an error.
if !self.gave {
self.gave = true;
buf.put_slice(&[0u8; 9]);
}
Poll::Ready(Ok(()))
}
}
impl Write for MockIo {
fn poll_write(
self: Pin<&mut Self>,
_: &mut Context<'_>,
_buf: &[u8],
) -> Poll<io::Result<usize>> {
// shouldn't be called for h1
unreachable!()
}
fn poll_flush(self: Pin<&mut Self>, _: &mut Context<'_>) -> Poll<io::Result<()>> {
Poll::Ready(Ok(()))
}
fn poll_shutdown(self: Pin<&mut Self>, _: &mut Context<'_>) -> Poll<io::Result<()>> {
Poll::Ready(Ok(()))
}
}
/// An empty body that sets `dropped` to true when dropped.
struct TrackedBody {
dropped: Arc<AtomicBool>,
}
impl Body for TrackedBody {
type Data = Bytes;
type Error = std::convert::Infallible;
fn poll_frame(
self: Pin<&mut Self>,
_: &mut Context<'_>,
) -> Poll<Option<Result<http_body::Frame<Bytes>, Self::Error>>> {
Poll::Ready(None)
}
}
impl Drop for TrackedBody {
fn drop(&mut self) {
self.dropped.store(true, Ordering::SeqCst);
}
}
Expected Behavior
My expectation of this program is that the body of the request is always dropped by the time that the only live value is the sender itself. Effectively this should never print body wasn't dropped.
Actual Behavior
Locally ~2m iterations show ~20 instances of the body not being dropped before the sender is fully dropped. This is how in Wasmtime's embedding it ended up showing as a timeout because we rely on the body being dropped to register when the request is sent and such (or an error occurred).
Additional Context
Some poking and prodding around things shows that one possible culprit here is this line which is a bit more robust using Tokio's try_recv (my guess is that try_recv was added after this was authored). Even with that, however, the program above still doesn't drop the body 100% of the time, and this seems due to the fact that even if close has been called on a channel it's possible for try_recv to return Empty (as opposed to Disconnected) if there's an outstanding permit of a message being sent. I think this is basically still a race between the sender/receiver where try_recv isn't enough, hyper would have to loop over try_recv.
Overall this is where I figured it'd be best to file an issue. I'd want to confirm the expectation that this program should reliably drop the body, and then also see what others' thoughts are on this.
- 主要言語
- Rust
- スター
- 16.3k
- フォーク
- 1.8k
- 平均マージ
- 2日 20時間
- マージ済み PR(30日)
- 14
環境構築
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
hyperium/hyper のほかの issue
-
C-feature
難易度 1/5 1時間未満 初心者へのやさしさ 65/100
hyperium/hyper#2652 · リアクション 4 件 ·
メンテナーはふだん 3 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 62/100
メンテナーはふだん 3 日以内に返信
-
C-feature
難易度 5/5 1週間以上 初心者へのやさしさ 35/100
hyperium/hyper#4186 · コメント 1 件 ·
メンテナーはふだん 3 日以内に返信
-
HTTP/1 client connection is never closed or pooled when a response completes while the request body is still unsent ((Reading::KeepAlive, Writing::Body) is a terminal state)対応中かも @BlackRabbitCoder が 12 日前に担当しました。 オープンC-bug S-waiting-on-author
hyperium/hyper#4176 · コメント 4 件 · 担当者 1 名 ·
メンテナーはふだん 3 日以内に返信
-
`Change graceful_shutdown function behavior` PR can cause tonic servers to hang `serve_with_incoming_shutdown` in two different cases再び着手できるかも @seanmonstar が 30 日前に担当しましたが、オープン中のプルリクエストはありません。 オープンA-http2 C-bug
hyperium/hyper#4170 · コメント 4 件 · 担当者 1 名 ·
メンテナーはふだん 3 日以内に返信
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
solana-foundation/pay-kit#341 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
anthropics/buffa#487 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
arkworks-rs/algebra#1161 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100
lbjlaq/Antigravity-Manager#3525 · コメント 2 件 · リアクション 1 件 ·
メンテナーはふだん 1 日以内に返信
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
rustdesk/rustdesk-server#708 ·