-
Notifications
You must be signed in to change notification settings - Fork 13.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
seg fault pushing on either side of a VecDeque #44800
Comments
Valgrind output with the allocator switched over to alloc_system:
|
Here is what I believe is a minimal reproduction: #![feature(global_allocator, alloc_system, allocator_api)]
extern crate alloc_system;
use std::collections::VecDeque;
use alloc_system::System;
#[global_allocator]
static ALLOCATOR: System = System;
fn main() {
let mut deque = VecDeque::with_capacity(32);
deque.push_front(0);
deque.reserve(31);
deque.push_back(0);
} Valgrind:
|
It looks like this was introduced two years ago in bfa0e1f. Specifically, Making a fix right now. |
You can otherwise end up in a situation where you don't actually resize but still call into handle_cap_increase which then corrupts head/tail. Closes rust-lang#44800
Fix capacity comparison in reserve You can otherwise end up in a situation where you don't actually resize but still call into handle_cap_increase which then corrupts head/tail. Closes #44800 Not totally sure the right way to write a test for this - there are some debug asserts the old bad behavior will hit but we don't build the stdlib with debug assertions by default. r? @gankro
You can otherwise end up in a situation where you don't actually resize but still call into handle_cap_increase which then corrupts head/tail. Closes rust-lang#44800 (cherry picked from commit 9733463)
This bug is referenced in CVE-2018-1000657:
|
You can otherwise end up in a situation where you don't actually resize but still call into handle_cap_increase which then corrupts head/tail. Closes rust-lang#44800
I've been seeing lots of bad behavior trying to use VecDeque. I've boiled it down to a relatively simple example which shows some of the bad behavior I was seeing and additionally seg faults.
This was with:
rustc 1.20.0 (f3d6973 2017-08-27)
binary: rustc
commit-hash: f3d6973
commit-date: 2017-08-27
host: x86_64-apple-darwin
release: 1.20.0
LLVM version: 4.0
and also rust 1.19
The output I expect to see is:
The output I get is:
Note that the fourth from the last byte should be D9.
Work around seems to be to use a large VecDeqeue capacity.
Here's the code:
The text was updated successfully, but these errors were encountered: