Uh oh!
There was an error while loading. Please reload this page.
bpo-46615: Don't crash when set operations mutate the sets - #31120
Conversation
Checked for refleaks: |
tim-one
left a comment
There was a problem hiding this comment.
Looks like the right approach to me, but Raymond is much more familiar with this code. Added a comment about something that confused me in the new tests.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
sweeneyde
commented
Feb 6, 2022
It's unclear to me why this doesn't crash with the added test cases: Lines 905 to 908 in 96b344c |
tim-one
commented
Feb 6, 2022
None of these ever "crashed" on my box (Windows). Instead they weirded out silently in various ways (seemingly infinite loops, or the process just stopped without an error exit code). Just about anything can happen when mucking with freed memory - including no visible symptoms at all. Try running in a mode that checks runtime memory use (like valgrind)? |
sweeneyde
commented
Feb 6, 2022
Aha: set_add_entry already does |
Uh oh!
There was an error while loading. Please reload this page.
| def __eq__(self, other): | ||
| if not enabled: | ||
| return False | ||
| if randrange(20) == 0: |
There was a problem hiding this comment.
Might be better to use something like a counter, so that these tests behave consistently. The current behavior might make the test pass or fail inconsistently depending on what the RNG produces.
There was a problem hiding this comment.
I'm personally okay with randomized tests, though I know others might feel differently. The test should pass for anything the RNG can give, and I'm personally more made more confident in code tested in millions of random situations, which ideally hit all of the corner cases I couldn't think of.
Uh oh!
There was an error while loading. Please reload this page.
Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>
miss-islington
commented
Feb 11, 2022
Thanks @sweeneyde for the PR 🌮🎉.. I'm working now to backport this PR to: 3.10. |
miss-islington
commented
Feb 11, 2022
Thanks @sweeneyde for the PR 🌮🎉.. I'm working now to backport this PR to: 3.9. |
miss-islington
commented
Feb 11, 2022
Sorry, @sweeneyde, I could not cleanly backport this to |
bedevere-bot
commented
Feb 11, 2022
GH-31284 is a backport of this pull request to the 3.10 branch. |
Ensure strong references are acquired whenever using `set_next()`. Added randomized test cases for `__eq__` methods that sometimes mutate sets when called. (cherry picked from commit 4a66615) Co-authored-by: Dennis Sweeney <36520290+sweeneyde@users.noreply.github.com>
bedevere-bot
commented
Feb 13, 2022
GH-31312 is a backport of this pull request to the 3.9 branch. |
…31120) (pythonGH-31312) Ensure strong references are acquired whenever using `set_next()`. Added randomized test cases for `__eq__` methods that sometimes mutate sets when called. (cherry picked from commit 4a66615)
Users of
set_nextshould callPy_INCREFon the resulting set keys to avoid use-after-free.https://bugs.python.org/issue46615