[swift-lldb-dev] Mysterious failure in lldbsuite.test.lldbtest.TestREPLThrowReturn
jingham at apple.com
Fri Aug 5 12:28:28 CDT 2016
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.
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.
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.
> 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
> it’s been failing consistently on Linux since this went in earlier today:
> 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
> 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
> 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
> 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
More information about the swift-lldb-dev