Closed
Description
Bug report
Bug description:
test_embed started failing for me recently on free threaded builds on both M1 Mac and Ubuntu (Intel). git bisect narrowed it down to a suspect commit. @colesbury this is probably for you.
Unfortunately, on my Mac I get this commit as the culprit:
% git bisect bad
5f1997896d9c3ecf92e9863177c452b468a6a2c8 is the first bad commit
commit 5f1997896d9c3ecf92e9863177c452b468a6a2c8
Author: Sam Gross <colesbury@gmail.com>
Date: Tue Jan 23 13:05:15 2024 -0500
gh-112984: Fix link error on free-threaded Windows build (GH-114455)
The test_peg_generator test tried to link the python313_d.lib library,
which failed because the library is now named python313t_d.lib. The
underlying problem is that the "compiler" attribute was not set when
we call get_libraries() from distutils.
Tools/peg_generator/pegen/build.py | 3 +++
1 file changed, 3 insertions(+)while in my Linux environment it says this:
% git bisect bad
b331381485c1965d1c88b7aee7ae9604aca05758 is the first bad commit
commit b331381485c1965d1c88b7aee7ae9604aca05758
Author: Sam Gross <colesbury@gmail.com>
Date: Tue Jan 16 16:42:15 2024 -0500
gh-112529: Track if debug allocator is used as underlying allocator (#113747)
* gh-112529: Track if debug allocator is used as underlying allocator
The GC implementation for free-threaded builds will need to accurately
detect if the debug allocator is used because it affects the offset of
the Python object from the beginning of the memory allocation. The
current implementation of `_PyMem_DebugEnabled` only considers if the
debug allocator is the outer-most allocator; it doesn't handle the case
of "hooks" like tracemalloc being used on top of the debug allocator.
This change enables more accurate detection of the debug allocator by
tracking when debug hooks are enabled.
* Simplify _PyMem_DebugEnabled
Include/internal/pycore_pymem.h | 3 +++
Include/internal/pycore_pymem_init.h | 2 ++
Include/internal/pycore_runtime_init.h | 1 +
Objects/obmalloc.c | 21 +++++++++++++++------
4 files changed, 21 insertions(+), 6 deletions(-)
(I backed up farther on my Linux box to find a good commit.) 16 January was a long time ago. My inclination is that the later commit is the culprit.
I then tried with the GIL enabled on main. Still an error. Hmmm... I went through the bisect process again on my Mac and landed on this as the putative culprit commit:
% git bisect good
441affc9e7f419ef0b68f734505fa2f79fe653c7 is the first bad commit
commit 441affc9e7f419ef0b68f734505fa2f79fe653c7
Author: Sam Gross <colesbury@gmail.com>
Date: Tue Jan 23 13:08:23 2024 -0500
gh-111964: Implement stop-the-world pauses (gh-112471)
The `--disable-gil` builds occasionally need to pause all but one thread. Some
examples include:
* Cyclic garbage collection, where this is often called a "stop the world event"
* Before calling `fork()`, to ensure a consistent state for internal data structures
* During interpreter shutdown, to ensure that daemon threads aren't accessing Python objects
This adds the following functions to implement global and per-interpreter pauses:
* `_PyEval_StopTheWorldAll()` and `_PyEval_StartTheWorldAll()` (for the global runtime)
* `_PyEval_StopTheWorld()` and `_PyEval_StartTheWorld()` (per-interpreter)
(The function names may change.)
These functions are no-ops outside of the `--disable-gil` build.
Include/cpython/pystate.h | 2 +-
Include/internal/pycore_ceval.h | 1 +
Include/internal/pycore_interp.h | 17 +++
Include/internal/pycore_llist.h | 3 +-
Include/internal/pycore_pystate.h | 51 +++++--
Include/internal/pycore_runtime.h | 7 +
Include/internal/pycore_runtime_init.h | 3 +
Include/pymacro.h | 3 +
Python/ceval_gil.c | 9 ++
Python/pystate.c | 269 +++++++++++++++++++++++++++++++--
10 files changed, 336 insertions(+), 29 deletions(-)
CPython versions tested on:
CPython main branch
Operating systems tested on:
Linux, macOS
Linked PRs
Metadata
Metadata
Assignees
Labels
The build process and cross-buildThe build process and cross-buildAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error