-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Fix capacity comparison in reserve #44802
Conversation
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
If the VecDeque tests are still in-module, you can assert on internal invariants in tests. iirc we do that a lot. |
I also believe we test with debug assertions on CI |
I added a run-pass-valgrind test, but unless I'm missing something I don't think we're actually running those in valgrind. compiletest needs a --valgrind-path to be passed to it and it doesn't look like anything actually does that. |
Oh, r=me on the actual fix. y'all can figure out the actual test. (I think it's fine to land without a test) |
📌 Commit 81bac74 has been approved by |
Alternatively, what about adding a test based on the example given by the reporter of #44800? It only depends on libstd, no? And most importantly, it has output you can compare. |
It depends on the allocator getting messed up in a very specific way which is pretty fragile. Directly looking for out of bounds reads should be more reliable. |
@bors: p=1 fixing a segfault and also beta accepted |
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
☀️ Test successful - status-appveyor, status-travis |
Backport #44802 to beta r? @alexcrichton
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