gh-142349: Implement PEP 810 - Explicit lazy imports#142351
Merged
pablogsal merged 169 commits intopython:mainfrom Feb 12, 2026
Merged
gh-142349: Implement PEP 810 - Explicit lazy imports#142351pablogsal merged 169 commits intopython:mainfrom
pablogsal merged 169 commits intopython:mainfrom
Conversation
…s on bad usage of lazy
Highlight lazy imports in the new REPL
|
|
|
|
|
|
|
|
|
|
|
|
|
|
pablogsal
added a commit
to pablogsal/cpython
that referenced
this pull request
Feb 12, 2026
The LOAD_GLOBAL specialization path in specialize_load_global_lock_held() called Py_DECREF(value) on the result of _PyDict_LookupIndexAndValue(), which returns a borrowed reference via _Py_dict_lookup(). This spurious DECREF silently corrupted the reference count of lazy import objects each time the adaptive specialization counter triggered while the lazy import was still present in the globals dict. This happens during concurrent lazy import reification with 8 or more threads in practice. The reason the thread count mattered is that with more threads racing through the barrier, more of them got a turn on the GIL to execute the LOAD_GLOBAL instruction (and trigger its adaptive specialization counter) while the first thread was still inside the import machinery resolving the lazy import. Each such trigger stole one reference from the lazy import object. With 2-7 threads, typically only 1-2 specialization triggers fired before the import completed, so the object survived. With 8+ threads, enough triggers accumulated (3 or more) to drive the reference count to zero while other threads still held pointers to the object, causing use-after-free. The fix removes the erroneous Py_DECREF from the specialization guard. The module attribute specialization path (specialize_module_load_attr) correctly handled the same case without a DECREF and served as confirmation that the LOAD_GLOBAL path was wrong. This commit also adds the lz_resolved field to PyLazyImportObject, which caches the resolved module after the first thread completes the import. Subsequent threads that were blocked on the import lock can then return the cached result immediately rather than re-importing. The _PyImport_LoadLazyImportTstate function now takes a strong reference to the lazy import at entry (to keep it alive across the GIL release inside _PyImport_AcquireLock) and releases it at every exit path, and a double-release of the import lock in the PySet_Add error path has also been corrected.
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
16 participants
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.
📚 Documentation preview 📚: https://cpython-previews--142351.org.readthedocs.build/