% git bisect bad5f1997896d9c3ecf92e9863177c452b468a6a2c8 is the first bad commitcommit 5f1997896d9c3ecf92e9863177c452b468a6a2c8Author: 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_generatortest 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 notset when    we callget_libraries() from distutils. Tools/peg_generator/pegen/build.py| 3 +++ 1 file changed, 3 insertions(+)

% git bisect badb331381485c1965d1c88b7aee7ae9604aca05758 is the first bad commitcommit b331381485c1965d1c88b7aee7ae9604aca05758Author: 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(-)

% git bisect good441affc9e7f419ef0b68f734505fa2f79fe653c7 is the first bad commitcommit 441affc9e7f419ef0b68f734505fa2f79fe653c7Author: 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(-)