[lldb-dev] How to debug "Python memory allocator called without holding the GIL" during LLDB tests?

[Adrian McCarthy via lldb-dev]

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\lldb\__init__.py", line
14461 in GetNumChildren
  File
"D:\src\llvm\mono\llvm-project\lldb\packages\Python\lldbsuite\test\python_api\formatters\TestFormattersSBAPI.py",
line 478 in test_force_synth_off
  File
"D:\src\llvm\mono\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py",
line 1738 in test_method
  File
"D:\src\llvm\mono\llvm-project\lldb\third_party\Python\module\unittest2\unittest2\case.py",
line 413 in runMethod
  File
"D:\src\llvm\mono\llvm-project\lldb\third_party\Python\module\unittest2\unittest2\case.py",
line 383 in run
  File
"D:\src\llvm\mono\llvm-project\lldb\third_party\Python\module\unittest2\unittest2\case.py",
line 458 in __call__
  File
"D:\src\llvm\mono\llvm-project\lldb\third_party\Python\module\unittest2\unittest2\suite.py",
line 117 in _wrapped_run
  File
"D:\src\llvm\mono\llvm-project\lldb\third_party\Python\module\unittest2\unittest2\suite.py",
line 115 in _wrapped_run
  File
"D:\src\llvm\mono\llvm-project\lldb\third_party\Python\module\unittest2\unittest2\suite.py",
line 85 in run
  File
"D:\src\llvm\mono\llvm-project\lldb\third_party\Python\module\unittest2\unittest2\suite.py",
line 66 in __call__
  File
"D:\src\llvm\mono\llvm-project\lldb\third_party\Python\module\unittest2\unittest2\runner.py",
line 165 in run
  File
"D:\src\llvm\mono\llvm-project\lldb\packages\Python\lldbsuite\test\dotest.py",
line 1443 in run_suite
  File "D:/src/llvm/mono/llvm-project/lldb/test/dotest.py", line 7 in
<module>

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 TestFormattersSBAPI.py 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

2.  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
PARTICULAR PURPOSE.

This program built for i386-pc-mingw32

Clues appreciated.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20190717/26c72af3/attachment.html>