How to debug "Python memory allocator called without holding the GIL" during LLDB tests?

Several LLDB tests on Windows are now failing for me like this:

Fatal Python error: Python memory allocator called without holding the GIL

Current thread 0x0000081c (most recent call first):
File “D:\src\llvm\build\mono\lib\site-packages\”, line 14461 in GetNumChildren
File “D:\src\llvm\mono\llvm-project\lldb\packages\Python\lldbsuite\test\python_api\formatters\”, line 478 in test_force_synth_off
File “D:\src\llvm\mono\llvm-project\lldb\packages\Python\lldbsuite\test\”, line 1738 in test_method
File “D:\src\llvm\mono\llvm-project\lldb\third_party\Python\module\unittest2\unittest2\”, line 413 in runMethod
File “D:\src\llvm\mono\llvm-project\lldb\third_party\Python\module\unittest2\unittest2\”, line 383 in run
File “D:\src\llvm\mono\llvm-project\lldb\third_party\Python\module\unittest2\unittest2\”, line 458 in call
File “D:\src\llvm\mono\llvm-project\lldb\third_party\Python\module\unittest2\unittest2\”, line 117 in _wrapped_run
File “D:\src\llvm\mono\llvm-project\lldb\third_party\Python\module\unittest2\unittest2\”, line 115 in _wrapped_run
File “D:\src\llvm\mono\llvm-project\lldb\third_party\Python\module\unittest2\unittest2\”, line 85 in run
File “D:\src\llvm\mono\llvm-project\lldb\third_party\Python\module\unittest2\unittest2\”, line 66 in call
File “D:\src\llvm\mono\llvm-project\lldb\third_party\Python\module\unittest2\unittest2\”, line 165 in run
File “D:\src\llvm\mono\llvm-project\lldb\packages\Python\lldbsuite\test\”, line 1443 in run_suite
File “D:/src/llvm/mono/llvm-project/lldb/test/”, line 7 in

I’m not sure how to go about debugging the problem. Note that the crash is in SWIG-generated code called by standard SBAPI tests that used to work just fine. (There are actually a few different tests that trigger the problem, but is typically the first and sometimes only one on any given run.)

I tried bisecting, but it turns out the problem coincided with an environmental change rather than a patch.

My environment changed to accommodate rL366243, which tries to ensure that the version of the Python interpreter detected by CMake matches the version of the Python libraries found by LLDBConfig, which has special logic on Windows so that the user can override the version of Python that LLDB uses.

That version check failed because CMake detected Python 2.7 rather than Python 3.6, which I had specified with PYTHON_HOME. This apparently has happened for a very long time, but it had never caused a problem until the version check was added. As far as I can tell, on Windows, LLDB uses the Python from PYTHON_HOME and/or the PATH and completely ignores the one CMake finds.

The only way I could satisfy the version check was to eliminate Python 2.7 from my machine so that CMake had no choice but to detect 3.6.

There was additional confusion, as the Python 2.7 uninstaller also removed make from my machine! (Weird, right?)

Ever since I restored make, running LLDB tests results in the error and stack reported at the top of this message. (Annoyingly, this sometimes causes a popup dialog that must be manually dismissed. Once you’ve dismissed it, the tests are usually hung. Canceling out of the tests leaves zombie Python processes that hold locks on various files, so there are additional manual steps to clean up.)

To summarize, the environmental changes are:

  1. Only one version of Python remains on the machine:

Python 3.6.8 (tags/v3.6.8:3c6b436a57, Dec 24 2018, 00:16:47) [MSC v.1916 64 bit (AMD64)] on win32

  1. Whatever version of make I was using vanished and was replaced by the one that comes with GnuWin32:

GNU Make 3.81
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A

This program built for i386-pc-mingw32

Clues appreciated.