| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
Fix a race condition where a thread could receive a partially-initialized module when another thread's import fails. The race occurs when: 1. Thread 1 starts importing, adds module to sys.modules 2. Thread 2 sees the module in sys.modules via the fast path 3. Thread 1's import fails, removes module from sys.modules 4. Thread 2 returns a stale module reference not in sys.modules The fix adds verification after the "skip lock" optimization in both Python and C code paths to check if the module is still in sys.modules. If the module was removed (due to import failure), we retry the import so the caller receives the actual exception from the import failure rather than a stale module reference. Changes: - Lib/importlib/_bootstrap.py: Add check after fast path in _find_and_load() - Python/import.c: Add checks in PyImport_GetModule() and PyImport_ImportModuleLevelObject() - Add regression test test_import_failure_race_condition() Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
|
🤖 New build scheduled with the buildbot fleet by @gpshead for commit 0a682cd 🤖 Results will be shown at: https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F143651%2Fmerge If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again. |
Sorry, something went wrong.
Add error checking inside the `if (mod_check != mod)` block to properly handle the case where import_get_module itself fails with an exception. Also refactor PyImport_GetModule to use an error label for cleanup. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
|
the few buildbot failures in the earlier round all looked like network issues. not rerunning those. |
Sorry, something went wrong.
|
🤖 New build scheduled with the buildbot fleet by @gpshead for commit 102845b 🤖 Results will be shown at: https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F143651%2Fmerge If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again. |
Sorry, something went wrong.
|
🤖 New build scheduled with the buildbot fleet by @gpshead for commit 102845b 🤖 Results will be shown at: https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F143651%2Fmerge If you want to schedule another build, you need to add the 🔨 test-with-refleak-buildbots label again. |
Sorry, something went wrong.
|
🤖 New build scheduled with the buildbot fleet by @encukou for commit 179d7bf 🤖 Results will be shown at: https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F143651%2Fmerge If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again. |
Sorry, something went wrong.
…onGH-143651) Fix a race condition where a thread could receive a partially-initialized module when another thread's import fails. The race occurs when: 1. Thread 1 starts importing, adds module to sys.modules 2. Thread 2 sees the module in sys.modules via the fast path 3. Thread 1's import fails, removes module from sys.modules 4. Thread 2 returns a stale module reference not in sys.modules The fix adds verification after the "skip lock" optimization in both Python and C code paths to check if the module is still in sys.modules. If the module was removed (due to import failure), we retry the import so the caller receives the actual exception from the import failure rather than a stale module reference. (cherry picked from commit ac8b5b6) Co-authored-by: Gregory P. Smith <68491+gpshead@users.noreply.github.com> Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
|
Sorry, @gpshead and @encukou, I could not cleanly backport this to 3.13 due to a conflict. cherry_picker ac8b5b6890006ee7254ea878866cb486ff835ecb 3.13 |
Sorry, something went wrong.
|
GH-144662 is a backport of this pull request to the 3.14 branch. |
Sorry, something went wrong.
…143651) (#144662) gh-143650: Fix importlib race condition on import failure (GH-143651) Fix a race condition where a thread could receive a partially-initialized module when another thread's import fails. The race occurs when: 1. Thread 1 starts importing, adds module to sys.modules 2. Thread 2 sees the module in sys.modules via the fast path 3. Thread 1's import fails, removes module from sys.modules 4. Thread 2 returns a stale module reference not in sys.modules The fix adds verification after the "skip lock" optimization in both Python and C code paths to check if the module is still in sys.modules. If the module was removed (due to import failure), we retry the import so the caller receives the actual exception from the import failure rather than a stale module reference. (cherry picked from commit ac8b5b6) Co-authored-by: Gregory P. Smith <68491+gpshead@users.noreply.github.com> Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
…onGH-143651) Fix a race condition where a thread could receive a partially-initialized module when another thread's import fails. The race occurs when: 1. Thread 1 starts importing, adds module to sys.modules 2. Thread 2 sees the module in sys.modules via the fast path 3. Thread 1's import fails, removes module from sys.modules 4. Thread 2 returns a stale module reference not in sys.modules The fix adds verification after the "skip lock" optimization in both Python and C code paths to check if the module is still in sys.modules. If the module was removed (due to import failure), we retry the import so the caller receives the actual exception from the import failure rather than a stale module reference. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> cherry picked from ac8b5b6
|
GH-144697 is a backport of this pull request to the 3.13 branch. |
Sorry, something went wrong.
…143651) (#144697) gh-143650: Fix importlib race condition on import failure (GH-143651) Fix a race condition where a thread could receive a partially-initialized module when another thread's import fails. The race occurs when: 1. Thread 1 starts importing, adds module to sys.modules 2. Thread 2 sees the module in sys.modules via the fast path 3. Thread 1's import fails, removes module from sys.modules 4. Thread 2 returns a stale module reference not in sys.modules The fix adds verification after the "skip lock" optimization in both Python and C code paths to check if the module is still in sys.modules. If the module was removed (due to import failure), we retry the import so the caller receives the actual exception from the import failure rather than a stale module reference. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> cherry picked from ac8b5b6
…onGH-143651) Fix a race condition where a thread could receive a partially-initialized module when another thread's import fails. The race occurs when: 1. Thread 1 starts importing, adds module to sys.modules 2. Thread 2 sees the module in sys.modules via the fast path 3. Thread 1's import fails, removes module from sys.modules 4. Thread 2 returns a stale module reference not in sys.modules The fix adds verification after the "skip lock" optimization in both Python and C code paths to check if the module is still in sys.modules. If the module was removed (due to import failure), we retry the import so the caller receives the actual exception from the import failure rather than a stale module reference. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
…onGH-143651) Fix a race condition where a thread could receive a partially-initialized module when another thread's import fails. The race occurs when: 1. Thread 1 starts importing, adds module to sys.modules 2. Thread 2 sees the module in sys.modules via the fast path 3. Thread 1's import fails, removes module from sys.modules 4. Thread 2 returns a stale module reference not in sys.modules The fix adds verification after the "skip lock" optimization in both Python and C code paths to check if the module is still in sys.modules. If the module was removed (due to import failure), we retry the import so the caller receives the actual exception from the import failure rather than a stale module reference. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
…onGH-143651) Fix a race condition where a thread could receive a partially-initialized module when another thread's import fails. The race occurs when: 1. Thread 1 starts importing, adds module to sys.modules 2. Thread 2 sees the module in sys.modules via the fast path 3. Thread 1's import fails, removes module from sys.modules 4. Thread 2 returns a stale module reference not in sys.modules The fix adds verification after the "skip lock" optimization in both Python and C code paths to check if the module is still in sys.modules. If the module was removed (due to import failure), we retry the import so the caller receives the actual exception from the import failure rather than a stale module reference. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
| Back | FazBrowse Home | New Git URL |
Fix race condition where a thread could receive a stale module reference when another thread's import fails. Adds verification after the "skip lock" fast path in both Python and C code paths to check if the module is still in sys.modules before returning it.