Mysterious failure in lldbsuite.test.lldbtest.TestREPLThrowReturn

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:

  Added an "inline-REPL" test case style that allows REPL tests without… · apple/swift-lldb@119fcb3 · GitHub

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'

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.

Jim

···

On Aug 4, 2016, at 9:56 PM, Douglas Gregor via swift-lldb-dev <swift-lldb-dev@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:

  Added an "inline-REPL" test case style that allows REPL tests without… · apple/swift-lldb@119fcb3 · GitHub

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@swift.org
https://lists.swift.org/mailman/listinfo/swift-lldb-dev

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@gmail.com <mailto:todd.fiala@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

···

On Aug 5, 2016, at 10:28 AM, Jim Ingham via swift-lldb-dev <swift-lldb-dev@swift.org> wrote:

Jim

On Aug 4, 2016, at 9:56 PM, Douglas Gregor via swift-lldb-dev <swift-lldb-dev@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:

  Added an "inline-REPL" test case style that allows REPL tests without… · apple/swift-lldb@119fcb3 · GitHub

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@swift.org
https://lists.swift.org/mailman/listinfo/swift-lldb-dev

_______________________________________________
swift-lldb-dev mailing list
swift-lldb-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-lldb-dev