<div dir="ltr"><div>I'm trying to figure out what's happening with the LLDB lit tests on Windows.  I'm not sure how to proceed with debugging this.</div><div><br></div><div>I execute this command:</div><div><br></div><div><font face="monospace, monospace" size="1">  ninja check-lldb</font></div><div><br></div><div>And several things happen very rapidly:</div><div><br></div><div>1.  On the console, I get one warning that says:</div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><font face="monospace, monospace" size="1">D:/src/llvm/mono/llvm-project/llvm\utils\lit\lit\discovery.py:121: ResourceWarning: unclosed file <_io.BufferedReader name=3></font></div><div><font face="monospace, monospace" size="1">key = (ts, path_in_suite)</font></div></blockquote><div>  </div><div>2.  Then I get several dozen messages of this form:</div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><font face="monospace, monospace" size="1">D:/src/llvm/mono/llvm-project/llvm\utils\lit\lit\TestRunner.py:727: ResourceWarning: unclosed file <_io.BufferedReader name=6></font></div><div><font face="monospace, monospace" size="1">res = _executeShCmd(cmd.rhs, shenv, results, timeoutHelper)</font></div></blockquote><div>      </div><div>3.  I get more than 200 dialog boxes that are essentially assertion failures in the CRT implementation of `close`.  The line complained about in the dialog is:</div><div>  </div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><font face="monospace, monospace" size="1">_VALIDATE_CLEAR_OSSERR_RETURN((fh >= 0 && (unsigned)fh < (unsigned)_nhandle), EBADF, -1);</font></div></blockquote><div>      </div><div>where `fh` is the value passed to `close`.  Indeed, `fh` typically has a value like 452 which is not in the range of 0 to `_nhandle` because `_nhandle` is 64.</div><div><br></div><div>Starting from 3, I tried to walk up the stack to see what's going on, but it's just the generic workings of the Python virtual machine.  The `close` call is happening because something in the .py code is calling `close`.  It's hard to see the Python code in the debugger.  It doesn't actually seem to be test code.</div><div><br></div><div>So I checked out the command line for one of those asserting processes to see if I could figure out which tests are exhibiting the problem.</div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><font face="monospace, monospace" size="1">"C:\python_35\python_d.exe" "-R" "-c" "from multiprocessing.spawn import spawn_main; spawn_main(pipe_handle=992, parent_pid=32640)" "--multiprocessing-fork"</font></div></blockquote><div>    </div><div>The `pipe_handle` value does not correspond to the value being passed to the `close`.  The `parent_pid` always refers to the parent lit command.</div><div><br></div><div>There always seem to be 32 Python processes in this state.  If I kill one, another is immediately spawned to replace it (creating a new assertion failure dialog).  I'm guessing that if I continued, there would be one for each test, and that somewhere there's a limit of 32 processes at a time.</div><div><br></div><div>So this kind of sounds like a lit bug, but other lit tests (as in `ninja check-llvm`) run just fine.  So it has something to do with how we invoke lit for LLDB.  The command being executed, per the build.ninja file, is:</div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><font face="monospace, monospace" size="1">cd /D D:\src\llvm\build\mono\tools\lldb\lit && C:\python_35\python_d.exe D:/src/llvm/build/mono/./bin/llvm-lit.py -sv --param lldb_site_config=D:/src/llvm/build/mono/tools/lldb/lit/lit.site.cfg --param lldb_unit_site_config=D:/src/llvm/build/mono/tools/lldb/lit/Unit/lit.site.cfg D:/src/llvm/build/mono/tools/lldb/lit</font></div></blockquote><div><br></div><div>The LLDB-specific things in the command are lit configs, with which I've been blissfully ignorant.  Should I head down that rabbit hole?  Could this be a problem with my environment?</div></div>