8000 `repr` of `threading.RLock` is erronous with the `_thread` module · Issue #134322 · python/cpython · GitHub
[go: up one dir, main page]

Skip to content

repr of threading.RLock is erronous with the _thread module #134322

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
YvesDup opened this issue May 20, 2025 · 4 comments
Closed

repr of threading.RLock is erronous with the _thread module #134322

YvesDup opened this issue May 20, 2025 · 4 comments
Labels
extension-modules C modules in the Modules dir type-bug An unexpected behavior, bug, or error

Comments

@YvesDup
Copy link
Contributor
YvesDup commented May 20, 2025

Bug report

Bug description:

import threading
 
r = threading.RLock()
 print(f"{r = }")

output is:

r = <unlocked _thread.RLock object owner=0 count=1 at 0x105a98720>

The threading.RLock.__repr__ seems to me erronous because when a threading.RLock is just created, its count attribute should be 0.
This error occurs only with the _thread module.

I can submit a PR.

CPython versions tested on:

CPython main branch

Operating systems tested on:

macOS

Linked PRs

@YvesDup YvesDup added the type-bug An unexpected behavior, bug, or error label May 20, 2025
@picnixz picnixz added the extension-modules C modules in the Modules dir label May 20, 2025
@picnixz
Copy link
Member
picnixz commented May 20, 2025

Yes, it's because of:

size_t count = self->lock.level + 1;

which doesn't check whether the lock is unlocked or not.

@YvesDup
Copy link
Contributor Author
YvesDup commented May 20, 2025

Yes, we have to check the lock state as in the rlock_recursion_count function from the _threadmodule.

@vstinner
Copy link
Member

It's a regression introduced in Python 3.14 by commit 67f6e08. cc @kumaraditya303

commit 67f6e08147bc005e460d82fcce85bf5d56009cf5
Author: Kumar Aditya <kumaraditya@python.org>
Date:   Mon Oct 14 14:06:31 2024 +0530

    gh-125139: use `_PyRecursiveMutex` in `_thread.RLock` (#125144)

@vstinner
Copy link
Member

Python 3.13 is not affected:

$ python3.13
Python 3.13.3+ (heads/mp_interrupt13:4d84782ac85, May 12 2025, 11:14:48) [GCC 15.0.1 20250329 (Red Hat 15.0.1-0)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import threading
>>> r=threading.RLock()
>>> r
<unlocked _thread.RLock object owner=0 count=0 at 0x7fb80bfa0d10>

vstinner pushed a commit that referenced this issue May 22, 2025
Fix the `__repr__` value of `threading.RLock` from `_thread` module, when just created.
miss-islington pushed a commit to miss-islington/cpython that referenced this issue May 22, 2025
Fix the `__repr__` value of `threading.RLock` from `_thread` module, when just created.
(cherry picked from commit fade146)

Co-authored-by: Duprat <yduprat@gmail.com>
vstinner pushed a commit that referenced this issue May 22, 2025
gh-134322: Fix `repr(threading.RLock)` (GH-134389)

Fix the `__repr__` value of `threading.RLock` from `_thread` module, when just created.
(cherry picked from commit fade146)

Co-authored-by: Duprat <yduprat@gmail.com>
lkollar pushed a commit to lkollar/cpython that referenced this issue May 26, 2025
Fix the `__repr__` value of `threading.RLock` from `_thread` module, when just created.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
extension-modules C modules in the Modules dir type-bug An unexpected behavior, bug, or error
Projects
None yet
Development

No branches or pull requests

3 participants
0