Re: [lldb-dev] Need help with failing LLDB tests on Windows

[Adrian McCarthy via lldb-dev]

Thanks for all the info and pointers.  That's helping me zero in on the
problem.

This category of the failures appears to all be dotest.py tests, so it
makes sense that it's the second import statement (per Pavel's explanation).

The module is not being found because it's actually named _lldb_d.pyd.
Apparently the `_d` suffix is because I'm building debug.  That seems
consistent with Stella's experience.

However, I've been building debug since before these problems arose.  (In
fact, I've been working on fixes for a small number of tests that only fail
in debug, because of an assertion that detects the problem.)

Ted's got me thinking that it was working due to a symlink that somehow got
blown away and/or isn't being recreated by the build.  If I recall
correctly, the symlinks on Windows are created using ln.exe, which may come
from GnuWin32 or from git/usr/bin.  In my case, it's git/usr/bin.  There
seem to have been many git updates in the past couple months, so perhaps
one of those updates tweaked ln.exe.  That could have been the trigger for
me.  Folks who didn't take the git update or who are configured to prefer
GnuWin32 tools might not have been affected.

I'll let you know what I eventually find.

On Wed, Nov 4, 2020 at 12:05 PM Ted Woodward  wrote:

> To expand a bit on what Pavel has written, the lldb module should be in
> \lib\site-packages\lldb . In that directory is a file, _lldb.pyd,
> that should be a copy of \bin\liblldb.dll .
>
> Do both files exist? Is _lldb.pyd a copy of liblldb.dll?
> See function create_relative_symlink in llvm-project/lldb/CMakeLists.txt
> for the copy (on non-unix hosts) procedure.
>
> Did you recently change your version of swig? LLDB requires swig 2, but,
> as you pointed out last year, there are issues with some versions of swig.
> We use 4.0.1 on Windows.
>
> > -Original Message-
> > From: lldb-dev  On Behalf Of Pavel
> Labath
> > via lldb-dev
> > Sent: Wednesday, November 4, 2020 2:49 AM
> > To: Adrian McCarthy ; LLDB  > d...@lists.llvm.org>
> > Subject: [EXT] Re: [lldb-dev] Need help with failing LLDB tests on
> Windows
> >
> > On 04/11/2020 01:53, Adrian McCarthy via lldb-dev wrote:
> > > For the past couple weeks, I've been trying to figure out why
> > > approximately 900+ LLDB tests have been failing for me on my local
> > > Windows builds.  Bisect turned up nothing--the "good" version that was
> > > working for me no longer works.  Since nobody else seems to be seeing
> > > these failures, I suspect it's something environmental.
> > >
> > > There are three categories of errors.  I'm currently focused on
> > > failures that look like this:
> > >
> > > FAIL: lldb-api :: lang/objc/unicode-string/TestUnicodeString.py
> (732
> > > of 2180)
> > >  TEST 'lldb-api ::
> > > lang/objc/unicode-string/TestUnicodeString.py' FAILED
> > > 
> > > Script:
> > > --
> > > C:/Program Files/Python38/python.exe
> > > D:/src/llvm/llvm-project/lldb\test\API\dotest.py -S nm -u CXXFLAGS
> > > -u CFLAGS --enable-crash-dialog --env
> > > LLVM_LIBS_DIR=D:/src/llvm/build/ninja_dbg/./lib --arch x86_64
> > > --build-dir D:/src/llvm/build/ninja_dbg/lldb-test-build.noindex -s
> > > D:/src/llvm/build/ninja_dbg/lldb-test-traces
> --lldb-module-cache-dir
> > > D:/src/llvm/build/ninja_dbg/lldb-test-build.noindex/module-cache-
> > lldb\lldb-api
> > > --clang-module-cache-dir
> > > D:/src/llvm/build/ninja_dbg/lldb-test-build.noindex/module-cache-
> > clang\lldb-api
> > > --executable D:/src/llvm/build/ninja_dbg/./bin/lldb.exe --compiler
> > > D:/src/llvm/build/ninja_dbg/bin/clang.exe --dsymutil
> > > D:/src/llvm/build/ninja_dbg/./bin/dsymutil.exe --filecheck
> > > D:/src/llvm/build/ninja_dbg/./bin/FileCheck.exe --yaml2obj
> > > D:/src/llvm/build/ninja_dbg/./bin/yaml2obj.exe --lldb-libs-dir
> > > D:/src/llvm/build/ninja_dbg/./lib
> > > D:\src\llvm\llvm-project\lldb\test\API\lang\objc\unicode-string -p
> > > TestUnicodeString.py
> > > --
> > > Exit Code: 1
> > >
> > > Command Output (stdout):
> > > --
> > > lldb version 12.0.0 (https://github.com/llvm/llvm-project.git
> > >  revision
> > > 0fdcd1ae1c988fa19d0c97e9e8678b93a0da)
> > >clang revision 0fdcd1ae1c988fa19d0c97e9e8678b93a0da
> > >llvm revision 0fdcd1ae1c988fa19d0c97e9e8678b93a0da
> > >
> > > --
> > > Command Output (stderr):
> > > --
> > > Traceback (most recent call last):
> > >File
> > > "D:\src\llvm\build\ninja_dbg\Lib\site-packages\lldb\__init__.py",
> > > line 35, in 
> > >  import _lldb
> > > ModuleNotFoundError: No module named '_lldb'
> > >
> > > During handling of the above exception, another exception occurred:
> > >
> > > Traceback (most recent call last):
> > >File "D:/src/llvm/llvm-project/lldb\test\API\dotest.py", line 7,
> > >   

Re: [lldb-dev] Remote connection expansion?

[Greg Clayton via lldb-dev]

> On Nov 4, 2020, at 1:28 PM, Mike Mestnik via lldb-dev 
>  wrote:
> 
> I'm looking for support running lldb over ssh.  I can forward the
> originating connection, but the run command is attempting to use
> random ports on localhost to attain another connection.  This fails as
> the localhost's are not the same.

When you say you want to run lldb over ssh, do you mean run "lldb-server" 
remotely and then have a local LLDB connect to that lldb-server? You are 
looking to avoid "lldb-server" from having to bind to port 0 and then tell you 
which port it was actually bound to?
> 
> Is there a platform, preferably real time, for lldb support?
> 
> One might ask why ssh, the basic answer is I don't want to open
> *another port on my remote host...  Even if I did I'd still have the
> same problem, a random port would fail to connect(this time because of
> a firewall).  The main answer is, without ssh, lldb is limited to
> running on local or VPN networks.  I'd rather use ssh than configure a
> VPN for this one use case.
> 
> * lldb doesn't sound like something one would want to host, even if
> connections were blocked from everywhere "else."
> 
> Now I'm attempting forward error correction by guessing where this
> topic could lead.  I would be willing to expand the network code to
> include domain sockets, to replace the whole idea of using, IMHO
> barbaric, port numbers.  This work could potentially include direct
> support for ssh.  I understand that this would likely be a breaking
> change, is there version negotiation?
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev