Uh oh!
There was an error while loading. Please reload this page.
gh-117657: Fix some races in tracebacks - #121748
Conversation
Uh oh!
There was an error while loading. Please reload this page.
Co-authored-by: Irit Katriel <1055913+iritkatriel@users.noreply.github.com>
iritkatriel
commented
Jul 22, 2024
LGTM, but I'd suggest to have another reviewer with more knowledge of the thread safe patterns. |
colesbury
left a comment
There was a problem hiding this comment.
I think the races in our tests involving tracebacks are broader than this.
The critical sections on getters and setters probably still makes sense, but I don't think they'll fix the traceback races.
The big problem is using sys._current_exceptions() to access exceptions for other threads while they are running. That function runs in a stop-the-world context, but the exception tracebacks are created lazily when other threads are resumed. I think that will still not be thread-safe even with this change.
| op->ob_refcnt = 1; | ||
| #else | ||
| op->ob_tid = _Py_ThreadId(); | ||
| _Py_atomic_store_uintptr_release(&op->ob_tid, _Py_ThreadId()); |
There was a problem hiding this comment.
I don't think we want to do this, at least not for now. I want to wait until we fix all the other races before we address new_reference because there are perf implications and the race is in practice benign.
The "release" memory order is also stronger (and more expensive on arm64) than necessary.
Uh oh!
There was an error while loading. Please reload this page.
kumaraditya303
commented
Jul 3, 2025
This is fixed on main under #128421 |
TSAN reported race:
and