aio-libs / multidict / 34789454978

87%

push

github

Fix a data race on entry->hash in to_dict()'s mark cleanup (#1450)

<!-- Thank you for your contribution! -->

## What do these changes do?

`to_dict()` (via `md_to_dict()`) marks every entry's hash while it walks
the table to collect keys, then clears all the marks in one pass via
`_md_restore_all_hashes()`, while holding `self`'s critical section.
That
excludes other mutators but not a lock-free reader: `__contains__` and
`get()`/`getone()`/`__getitem__` load the same field with an atomic op
and no lock at all. `_md_restore_all_hashes()`'s clear was a plain,
non-atomic store, racing that atomic load under the free-threaded
build. This routes it through the existing `_md_entry_store_hash()`
helper, matching the pattern already used for the sibling mark/unmark
sites in `md_find_next()`/`md_finder_cleanup()`/`md_post_update()`
fixed by #1448.

This is a C-extension-only fix: the pure-Python `to_dict()` has no
equivalent hash-marking scheme, so there is nothing to change there.

## Are there changes in behavior for the user?

No. This only affects the free-threaded build's internal memory-model
correctness; there is no change to observable behavior.

## Is it a substantial burden for the maintainers to support this?

No, it's a small, self-contained fix mirroring the existing atomic-op
pattern already used elsewhere in `hashtable.h`.

## Related issue number

Found via a Greptile review comment on #1447; not otherwise linked to
an issue.

## Checklist

- [x] I think the code is well written
- [x] Unit tests for the changes exist
- [x] Documentation reflects the changes
- [ ] If you provide code modification, please add yourself to
`CONTRIBUTORS.txt` (N/A: no `CONTRIBUTORS.txt` in this repo)
- [x] Add a new news fragment into the `CHANGES/` folder
- [x] `make doc-spelling` passes and any new technical words are added
to `docs/spelling_wordlist.txt`

<details>
<summary>Agent run details (optional, for reviewers)</summary>

Race confirmed with ThreadSaniti... (continued)

710 of 1420 branches covered (50.0%)

Branch coverage included in aggregate %.

18 of 18 new or added lines in 1 file covered. (100.0%)

5097 of 5343 relevant lines covered (95.4%)

1.91 hits per line