suharev7
/
clickhouse-rs
/
53
/
3
84%
master: 87%
master: 87%
|
Ran
|
Files
39
|
Run time
4s
|
Badge
Embed ▾
README BADGES
|
coverage: 84.012%. Remained the same
travis-ci-com
web-flowFor new connections handling, hold lock over len check and iteration When checking whether new connections are ready, there's a lock on the new connections at two points in time: - checking the len of the connections Vec - iterating over the connections Vec and swapping out ones that are ready. A race condition (and subsequent panic) may occur when: - two handles try to get a new handle, which calls `poll`, which calls `handle_futures` which checks if new connections are ready. - handle 1 gains lock, checks len of `new` connections, gets result of 1, and releases lock. - handle 2 does the same. - handle 1 iterates over `0..len`, where len is 1. Because the client is ready, handle 1 gets lock, removes it from `new` and puts it in `idle`, and releases lock. - handle 2 iterates over `0..len`, where len is 1. Because handle 1 already removed the connection, in `new`, the len of `new` is actually 0. After handle 2 acquires the lock, it tries to access `new[i]` but panics because `new` is empty. The solution is to hold the lock between the time the length of `new` is checked, and the time that `new` is iterated over using that len. Addresses the following error: ``` thread 'arbiter:3c5ae82c-8c17-442d-9b94-4285fed8c742:actix-net-worker-7' panicked at 'index out of bounds: the len is 0 but the index is 0', /rustc/ec194646f/src/libcore/slice/mod.rs:2461:14 stack backtrace: 0: <unknown> 1: <unknown> 2: <unknown> 3: <unknown> 4: std::panicking::rust_panic_with_hook 5: <unknown> 6: rust_begin_unwind 7: core::panicking::panic_fmt 8: core::panicking::panic_bounds_check 9: <unknown> 10: <clickhouse_rs::pool::futures::get_handle::GetHandle as futures::future::Future>::poll ... ```
2312 of 2752 relevant lines covered (84.01%)
0.84 hits per line
