[swift-lldb-dev] Mysterious failure in lldbsuite.test.lldbtest.TestREPLThrowReturn

Mon Aug 8 10:33:20 CDT 2016

> On Aug 5, 2016, at 10:28 AM, Jim Ingham via swift-lldb-dev <swift-lldb-dev at swift.org> wrote:
> 
> The SWIG Python bindings need to be updated.  Sean added an API to the SB API's which is used in this test.  That's what the SetREPLMode attribute error - we're calling a method on a class that isn't present in the Python representation of the class.
> 
> In OS X builds, for instance, a change in the SB API's would cause the SWIG bindings to get regenerated, and everything would be fine.  But we decided not to require the linux builders to have SWIG, so for that environment the bindings need to be manually updated.  For now, this is a by hand type thing, and a job Todd has up to now done.
> 

Huh, that’s weird. I answered this from my todd.fiala at gmail.com <mailto:todd.fiala at gmail.com> account while away on vacation, but I’m not seeing it show up on this thread.  I’ll have to track that down.

I have a task on my plate to automate this step.  Up until now, I generally am doing the merges that bring over SBAPI changes, and I generally update the static bindings at that time.

I think the static bindings get used on macOS in some places as well - machines using public macOS don’t have a version of swig on them by default, and I think several of our CI are configured this way.

> When we were originally dealing with what to do about building lldb on platforms that didn't have SWIG installed, we suggested that the result of running SWIG be a file that is checked in to lldb and not rebuilt by default.  Then we would have the SWIG step be a maintainer-mode operation that you would do whenever you updated any of the SB API's, checking in the result along with the SB API changes.  But for some reason that was never clear to me, folks at Google were strongly opposed to this, so we ended up in this ad hoc arrangement for the Linux CI's instead.
> 
> I actually don't know what Todd does to get this updated file onto the Linux builders.  If nobody else knows, I'll find out from him when he gets back on Monday so we have a couple of people who know the incantation.
> 

The steps are pretty simple:

1. Do a build on a machine with swig 1.3.40 installed.
2. Copy the LLDBWrapPython.cpp and lldb.py from the build directory into {lldb-source-root}/scripts/Python/static-binding.
3. Check those in.

The files in that directory are used if (1) swig can’t be found and (2) a flag is specified which says that it is okay to use static bindings.  The Swift build-script-based builds specify that flag, as does the Xcode-driven build, so we’ll use the static bindings from the scripts/Python/static-binding dir in that case.

> Note, we added this new SB API way of running REPL tests because the other way of testing them - feeding text at the REPL as a sub-process directly and using pexpect to handle the traffic - was failing intermittently. Seems pexpect is actually a poor substitute for expect, doesn't work at all on Windows, and is flakey on Linux.  It actually seems pretty solid on OS X, which I guess is yay for us, but doesn't help with the Linux CI's...  
> 
> I see you reverted the test back to this flakey but xfailed state.  If it stays that way till Todd gets back on Monday, that won't do any harm.
> 

I’ll go ahead and update these for GitHub swift-lldb/master later this morning.

-Todd

> Jim
> 
> 
>> On Aug 4, 2016, at 9:56 PM, Douglas Gregor via swift-lldb-dev <swift-lldb-dev at swift.org> wrote:
>> 
>> Anyone know what’s going on here? There’s very little information in the log from
>> 
>> 	https://ci.swift.org/job/swift-PR-Linux-smoke-test/565/consoleFull#-161933955fca400bf-2f4a-462e-b517-e058d770b2d7
>> 
>> it’s been failing consistently on Linux since this went in earlier today:
>> 
>> 	https://github.com/apple/swift-lldb/commit/119fcb317c16ec30c20b63a1838da39302317352
>> 
>> making smoke testing mostly useless.
>> 
>> 	- Doug
>> 
>> ======================================================================
>> ERROR: test_with_dwarf (lldbsuite.test.lldbtest.TestREPLThrowReturn)
>> ----------------------------------------------------------------------
>> Traceback (most recent call last):
>> File "/home/buildnode/jenkins/workspace/swift-PR-Linux-smoke-test/lldb/packages/Python/lldbsuite/test/lldbinrepl.py", line 129, in __test_with_dwarf
>>   self.do_test()
>> File "/home/buildnode/jenkins/workspace/swift-PR-Linux-smoke-test/lldb/packages/Python/lldbsuite/test/lldbinrepl.py", line 154, in do_test
>>   parser.handle_breakpoint(self, thread, breakpoint_id)
>> File "/home/buildnode/jenkins/workspace/swift-PR-Linux-smoke-test/lldb/packages/Python/lldbsuite/test/lldbinrepl.py", line 65, in handle_breakpoint
>>   options.SetREPLMode(True)
>> File "/home/buildnode/jenkins/workspace/swift-PR-Linux-smoke-test/buildbot_linux/lldb-linux-x86_64/lib/python2.7/site-packages/lldb/__init__.py", line 3987, in <lambda>
>>   __getattr__ = lambda self, name: _swig_getattr(self, SBExpressionOptions, name)
>> File "/home/buildnode/jenkins/workspace/swift-PR-Linux-smoke-test/buildbot_linux/lldb-linux-x86_64/lib/python2.7/site-packages/lldb/__init__.py", line 79, in _swig_getattr
>>   raise AttributeError(name)
>> AttributeError: SetREPLMode
>> Config=x86_64-/home/buildnode/jenkins/workspace/swift-PR-Linux-smoke-test/buildbot_linux/llvm-linux-x86_64/bin/clang-3.9
>> ----------------------------------------------------------------------
>> Ran 1 test in 2.985s
>> 
>> RESULT: FAILED (0 passes, 0 failures, 1 errors, 0 skipped, 0 expected failures, 0 unexpected successes)
>> Session logs for test failures/errors/unexpected successes can be found in directory '2016-08-04-23_42_49' 
>> _______________________________________________
>> swift-lldb-dev mailing list
>> swift-lldb-dev at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-lldb-dev
> 
> _______________________________________________
> swift-lldb-dev mailing list
> swift-lldb-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-lldb-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-lldb-dev/attachments/20160808/9271f564/attachment.html>