[TSRM] Roll back id_count when resource type allocation fails - #291
Open
iliaal wants to merge 1 commit into
Open
[TSRM] Roll back id_count when resource type allocation fails#291iliaal wants to merge 1 commit into
iliaal wants to merge 1 commit into
Conversation
ts_allocate_id() and ts_allocate_fast_id() incremented id_count before growing resource_types_table; on realloc failure (or exhausted fast reservation space) they returned 0 while id_count still counted the new slot, leaving an uninitialized hole that later allocations and thread storage setup would read. Roll back id_count (and tsrm_reserved_pos for the fast path) on all three failure paths so state stays consistent. Sibling audit: tsrm_update_active_threads() and allocate_new_resource() have unchecked allocator returns, which is an OOM-hardening gap outside this slot-hole fix.
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
1 participant
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.
ts_allocate_id() and ts_allocate_fast_id() bump id_count before growing resource_types_table or reserving fast-path space, so realloc failure or reservation exhaustion leaves id_count counting an uninitialized slot; allocations and per-thread setup then read that hole. Both roll id_count back under the mutex on either condition, restoring tsrm_reserved_pos on the fast path, keeping table, reservation and thread storage counts consistent. tsrm_update_active_threads() and allocate_new_resource() leave allocator returns unchecked (separate gap). No runtime repro (ZTS plus a failing realloc).