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. |
sfackler
added
the
beta-nominated
|
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. |
carols10cents
added
the
S-waiting-on-bors
|
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. |
alexcrichton
added
the
T-libs-api
|
@bors: p=1 fixing a segfault and also beta accepted |
alexcrichton
added
the
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
alexcrichton
removed
the
beta-nominated
6 participants
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