<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 5, 2016, at 10:28 AM, Jim Ingham via swift-lldb-dev <<a href="mailto:swift-lldb-dev@swift.org" class="">swift-lldb-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">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.<br class=""><br 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.<br class=""><br class=""></div></div></blockquote><div><br class=""></div><div>Huh, that’s weird. I answered this from my <a href="mailto:todd.fiala@gmail.com" class="">todd.fiala@gmail.com</a> account while away on vacation, but I’m not seeing it show up on this thread. I’ll have to track that down.</div><div><br class=""></div><div>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.</div><div><br class=""></div><div>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.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">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.<br class=""><br class="">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.<br class=""><br class=""></div></div></blockquote><div><br class=""></div><div>The steps are pretty simple:</div><div><br class=""></div><div>1. Do a build on a machine with swig 1.3.40 installed.</div><div>2. Copy the LLDBWrapPython.cpp and lldb.py from the build directory into {lldb-source-root}/scripts/Python/static-binding.</div><div>3. Check those in.</div><div><br class=""></div><div>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.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">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... <br class=""><br class="">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.<br class=""><br class=""></div></div></blockquote><div><br class=""></div><div>I’ll go ahead and update these for GitHub swift-lldb/master later this morning.</div><div><br class=""></div><div>-Todd</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">Jim<br class=""><br class=""><br class=""><blockquote type="cite" class="">On Aug 4, 2016, at 9:56 PM, Douglas Gregor via swift-lldb-dev <<a href="mailto:swift-lldb-dev@swift.org" class="">swift-lldb-dev@swift.org</a>> wrote:<br class=""><br class="">Anyone know what’s going on here? There’s very little information in the log from<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><a href="https://ci.swift.org/job/swift-PR-Linux-smoke-test/565/consoleFull#-161933955fca400bf-2f4a-462e-b517-e058d770b2d7" class="">https://ci.swift.org/job/swift-PR-Linux-smoke-test/565/consoleFull#-161933955fca400bf-2f4a-462e-b517-e058d770b2d7</a><br class=""><br class="">it’s been failing consistently on Linux since this went in earlier today:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>https://github.com/apple/swift-lldb/commit/119fcb317c16ec30c20b63a1838da39302317352<br class=""><br class="">making smoke testing mostly useless.<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug<br class=""><br class="">======================================================================<br class="">ERROR: test_with_dwarf (lldbsuite.test.lldbtest.TestREPLThrowReturn)<br class="">----------------------------------------------------------------------<br class="">Traceback (most recent call last):<br class=""> File "/home/buildnode/jenkins/workspace/swift-PR-Linux-smoke-test/lldb/packages/Python/lldbsuite/test/lldbinrepl.py", line 129, in __test_with_dwarf<br class=""> self.do_test()<br class=""> File "/home/buildnode/jenkins/workspace/swift-PR-Linux-smoke-test/lldb/packages/Python/lldbsuite/test/lldbinrepl.py", line 154, in do_test<br class=""> parser.handle_breakpoint(self, thread, breakpoint_id)<br class=""> File "/home/buildnode/jenkins/workspace/swift-PR-Linux-smoke-test/lldb/packages/Python/lldbsuite/test/lldbinrepl.py", line 65, in handle_breakpoint<br class=""> options.SetREPLMode(True)<br class=""> 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><br class=""> __getattr__ = lambda self, name: _swig_getattr(self, SBExpressionOptions, name)<br class=""> 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<br class=""> raise AttributeError(name)<br class="">AttributeError: SetREPLMode<br class="">Config=x86_64-/home/buildnode/jenkins/workspace/swift-PR-Linux-smoke-test/buildbot_linux/llvm-linux-x86_64/bin/clang-3.9<br class="">----------------------------------------------------------------------<br class="">Ran 1 test in 2.985s<br class=""><br class="">RESULT: FAILED (0 passes, 0 failures, 1 errors, 0 skipped, 0 expected failures, 0 unexpected successes)<br class="">Session logs for test failures/errors/unexpected successes can be found in directory '2016-08-04-23_42_49' <br class="">_______________________________________________<br class="">swift-lldb-dev mailing list<br class="">swift-lldb-dev@swift.org<br class="">https://lists.swift.org/mailman/listinfo/swift-lldb-dev<br class=""></blockquote><br class="">_______________________________________________<br class="">swift-lldb-dev mailing list<br class=""><a href="mailto:swift-lldb-dev@swift.org" class="">swift-lldb-dev@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-lldb-dev<br class=""></div></div></blockquote></div><br class=""></body></html>