Separate correctness and memory tests for ConcurrentMap, LockFreeStack, and LockFreeQueue #25392
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Previously, we were locking down the expected memleak behavior for these tests. Not all of our nightly jobs run futures but we would still like to run these as correctness tests. We also have infrastructure for detecting tests that leak memory so it's better to leverage that rather than having these as futures anyway. So, I've rewritten these to not pass `--memLeaks` and then added some separate "memLeak" only tests. --- Signed-off-by: Andy Stone <[email protected]>
e-kayrakli
approved these changes
Jun 28, 2024
--- Signed-off-by: Andy Stone <[email protected]>
stonea
force-pushed
the
concurrent_map_tests
branch
from
62910f2 to
4e48dd0
Compare
stonea
added a commit
that referenced
this pull request
Jul 1, 2024
…e doc for modules to indicate not x86 exclusive (#25413) The following PR includes changes I should have merged into #25392. Basically updating the docs for `LockFreeQueue`/`LockFreeStack` to indicate they're no longer exclusive for x86 and remove the future files for these modules now that these are meant to be correctness tests (since the prior PR moved the memLeak tests into different dirs). [Reviewed by nobody; simple fix for prior PR #25392]
stonea
added a commit
that referenced
this pull request
Jul 3, 2024
…/LockFreeQueue (#25422) This should have been included as part of #25392. Basically I intended to have some symlinks for memory tests for `LockFreeStack`/`LockFreeQueue` but forgot to `git add` them to my commit. This PR fixes it. Looking at last night's test jobs the correctness tests part of that PR ran as expected. [Reviewed by nobody; add files missing from prior PR]
stonea
added a commit
that referenced
this pull request
Jul 8, 2024
PR #25392 replaced a set of futures that were locking down that (for ConcurrentMap, LockFreeQueue, and LockFreeStack) we failed with memory leaks (when passing '--memLeaks') with normal correctness tests. To lock down the known memory failures I also created a handful of other tests that lock down the "known leak" when passing in '--memLeaks' by execopt (this is the precedent we have for other known leaks as we have a script that detects such tests). Anyway, we don't want the pure correctness tests to fail on our memleak job so we should skip them. This PR adjusts the skipif files to do that. [Reviewed by nobody; simple test update]
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
All of our tests for ConcurrentMap, LockFreeStack, and LockFreeQueue are futures locking down behavior when using
--memLeaks. This is a bit problematic because:.badbehavior so these tests would never catch correctness issues.To reesolve all this, I've removed the futures and changed these to correctness tests when not using
--memLeaks. I've also created separate symlinked versions of some of these tests that still run with--memLeaks. I didn't do this for all the tests since some of them have non-deterministic leaking behavior but I feel capturing this subset is sufficient for memory tracking purposes.Edit: turns out all the tests have non deterministic memleaking behavior (I'm guessing based on
maxTaskParso I've ended up prediffing out the specifics of the memleak behavior and opting instead to just lock down that memory leaks occur).