Skip to content

Conversation

@youknowone
Copy link
Contributor

@youknowone youknowone commented Dec 5, 2025

retSize was ignored
bufSize is the size of buffer including uninitializd buffers.
Copy link
Member

@serhiy-storchaka serhiy-storchaka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The current code works in most cases, because the size of the buffer is determined by the previous call of RegQueryValueExW(). But this will not work in case of race condition, when the value was change between the RegQueryValueExW() calls. Please mention race condition in the NEWS entry.

It would also be nice to add tests. Try to write different values (perhaps b'ham' and b'spam' would be enough) in one thread while simultaneously reading them in other thread and checking the the result is one of possible written value. If it fails with unpatched code and passes with patched code, then we have a working test. If this does not work, try something other. In worst case, if it is too difficult to reproduce the bug, we can accept the fix without working test.

@youknowone
Copy link
Contributor Author

@serhiy-storchaka Isn't it also possible when rc == ERROR_MORE_DATA hits? That will be easier to check. Unfortunately I know barely nothing about windows api. How it will be?

@serhiy-storchaka
Copy link
Member

I think that rc == ERROR_MORE_DATA only hits when there is a race condition. So, the code was already written to handle race condition, it just contains a bug, but since this was not tested, it was not discovered until your report.

@@ -0,0 +1 @@
Fix winreg.QueryValueEx not to accidently read garbage buffer
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Fix winreg.QueryValueEx not to accidently read garbage buffer
Fix :func:`winreg.QueryValueEx` to not accidentally read garbage buffer.

@youknowone
Copy link
Contributor Author

@serhiy-storchaka Thanks! It was reproducible with the test and I confirmed it is fixed after patch.

Copy link
Member

@serhiy-storchaka serhiy-storchaka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great!

How long does it take to complete the new test?

Comment on lines 331 to 334
use_first = True
while not done:
val = values[0] if use_first else values[1]
use_first = not use_first
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think itertools.cycle() can be used here.

continue
# The result must be one of the written values,
# not garbage data from uninitialized buffer
if result not in values:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not simply use assertIn()?

Comment on lines 341 to 346
for _ in range(1000):
try:
result, typ = QueryValueEx(key, 'test_value')
except FileNotFoundError:
# Value not yet created
continue
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Several first iterations can be a blank shot. In worst case this loop can finish before the writer thread starts. I the test is repeated several times, you can see here the result of the previous test before the writer thread starts.

You can use an event. Set it in the writer after the first write and wait for it in the main thread before starting the loop. Then read will never fail.

@youknowone
Copy link
Contributor Author

Thanks, I applied the review. The test takes 0.005 seconds on my machine.

Copy link
Member

@serhiy-storchaka serhiy-storchaka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. 👍

@serhiy-storchaka serhiy-storchaka enabled auto-merge (squash) December 9, 2025 10:54
@serhiy-storchaka serhiy-storchaka added needs backport to 3.13 bugs and security fixes needs backport to 3.14 bugs and security fixes labels Dec 9, 2025
@serhiy-storchaka serhiy-storchaka merged commit 3ec941b into python:main Dec 9, 2025
46 checks passed
@miss-islington-app
Copy link

Thanks @youknowone for the PR, and @serhiy-storchaka for merging it 🌮🎉.. I'm working now to backport this PR to: 3.13, 3.14.
🐍🍒⛏🤖

miss-islington pushed a commit to miss-islington/cpython that referenced this pull request Dec 9, 2025
@miss-islington-app
Copy link

Sorry, @youknowone and @serhiy-storchaka, I could not cleanly backport this to 3.13 due to a conflict.
Please backport using cherry_picker on command line.

cherry_picker 3ec941b364778bce4fac6c6100730e120b426849 3.13

@bedevere-app
Copy link

bedevere-app bot commented Dec 9, 2025

GH-142453 is a backport of this pull request to the 3.14 branch.

@bedevere-app bedevere-app bot removed the needs backport to 3.14 bugs and security fixes label Dec 9, 2025
serhiy-storchaka pushed a commit that referenced this pull request Dec 9, 2025
serhiy-storchaka pushed a commit to serhiy-storchaka/cpython that referenced this pull request Dec 9, 2025
@bedevere-app
Copy link

bedevere-app bot commented Dec 9, 2025

GH-142456 is a backport of this pull request to the 3.13 branch.

@bedevere-app bedevere-app bot removed the needs backport to 3.13 bugs and security fixes label Dec 9, 2025
@serhiy-storchaka
Copy link
Member

I just noticed that the NEWS entry was misplaced. It should be in the "Library" section. I'll fix this in other issue, but please take a note for future.

serhiy-storchaka added a commit that referenced this pull request Dec 9, 2025
@youknowone youknowone deleted the gh-142282 branch December 10, 2025 00:26
@youknowone
Copy link
Contributor Author

Oh, you're right. Sorry about that

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants