Fix out-of-bounds panic caused by use of undefined indices when the free queue storage is resized.#2
Merged
Conversation
…ree queue storage is resized. Before this change, the following sequence of events was possible: 1. The current free queue storage region (between head and tail) wraps around the end of the array 2. An entry is added via `didGetNewHandleNoResize`, which resizes the free queue backing slice 3. The region between head and tail now contains an undefined entry I initially fixed this by always preferring to use entries from the free list, but the problem with that solution is that a smaller number of indices are used, and their cycle counts are incremented more often, which would increase the chances of a stale handle accidentally aliasing a re-used handle. This new strategy is to prefer entries from the free list only if it spans past the end of the storage buffer, and to prefer unused entries otherwise.
kcbanner
force-pushed
the
fixup_ring_buffer_resize
branch
from
19e1552 to
06e4000
Compare
hazeycode
approved these changes
Apr 21, 2025
Member
hazeycode
left a comment
hazeycode
left a comment
There was a problem hiding this comment.
Nice job! Looks good to me.
Note to self: We should devise benchmarks and more stress tests so we can better evaluate the impact of changes like this one.
scixor
pushed a commit
to scixor/zpool
that referenced
this pull request
May 17, 2026
…ree queue storage is resized. (zig-gamedev#2) Before this change, the following sequence of events was possible: 1. The current free queue storage region (between head and tail) wraps around the end of the array 2. An entry is added via `didGetNewHandleNoResize`, which resizes the free queue backing slice 3. The region between head and tail now contains an undefined entry I initially fixed this by always preferring to use entries from the free list, but the problem with that solution is that a smaller number of indices are used, and their cycle counts are incremented more often, which would increase the chances of a stale handle accidentally aliasing a re-used handle. This new strategy is to prefer entries from the free list only if it spans past the end of the storage buffer, and to prefer unused entries otherwise.
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Before this change, the following sequence of events was possible:
didGetNewHandleNoResize, which resizes the free queue backing sliceI initially fixed this by always preferring to use entries from the free list, but the problem with that solution is that a smaller number of indices are used, and their cycle counts are incremented more often, which would increase the chances of a stale handle accidentally aliasing a re-used handle.
This new strategy is to prefer entries from the free list only if it spans past the end of the storage buffer, and to prefer unused entries otherwise.