A combination of: 1. Updating to a known good release according to buildbot 2. using Ubuntu 14.04 3. compiling release using clang-4.0 4. using the dotest command line that buildbot uses 5. specifying gcc-4.8 instead of the locally compiled clang
has most of the tests passing, with a handful of unexpected successes: UNEXPECTED SUCCESS: TestRegisterVariables.RegisterVariableTestCase.test_and_run_command_dwarf (lang/c/register_variables/TestRegisterVariables.py) UNEXPECTED SUCCESS: TestRegisterVariables.RegisterVariableTestCase.test_and_run_command_dwo (lang/c/register_variables/TestRegisterVariables.py) UNEXPECTED SUCCESS: TestExitDuringBreak.ExitDuringBreakpointTestCase.test_dwarf (functionalities/thread/exit_during_break/TestExitDuringBreak.py) UNEXPECTED SUCCESS: TestExitDuringBreak.ExitDuringBreakpointTestCase.test_dwo (functionalities/thread/exit_during_break/TestExitDuringBreak.py) UNEXPECTED SUCCESS: TestThreadStates.ThreadStateTestCase.test_process_interrupt_dwarf (functionalities/thread/state/TestThreadStates.py) UNEXPECTED SUCCESS: TestThreadStates.ThreadStateTestCase.test_process_interrupt_dwo (functionalities/thread/state/TestThreadStates.py) UNEXPECTED SUCCESS: TestRaise.RaiseTestCase.test_restart_bug_dwarf (functionalities/signal/raise/TestRaise.py) UNEXPECTED SUCCESS: TestRaise.RaiseTestCase.test_restart_bug_dwo (functionalities/signal/raise/TestRaise.py) UNEXPECTED SUCCESS: TestMultithreaded.SBBreakpointCallbackCase.test_sb_api_listener_resume_dwarf (api/multithreaded/TestMultithreaded.py) UNEXPECTED SUCCESS: TestMultithreaded.SBBreakpointCallbackCase.test_sb_api_listener_resume_dwo (api/multithreaded/TestMultithreaded.py) UNEXPECTED SUCCESS: lldbsuite.test.lldbtest.TestPrintf.test_with_dwarf (lang/cpp/printf/TestPrintf.py) UNEXPECTED SUCCESS: lldbsuite.test.lldbtest.TestPrintf.test_with_dwo (lang/cpp/printf/TestPrintf.py) This looks different than another user's issue: http://lists.llvm.org/pipermail/lldb-dev/2016-February/009504.html I also tried gcc-4.9.4 (via the ubuntu-toolchain-r ppa) and got a different set of problems: FAIL: TestNamespaceDefinitions.NamespaceDefinitionsTestCase.test_expr_dwarf (lang/cpp/namespace_definitions/TestNamespaceDefinitions.py) FAIL: TestNamespaceDefinitions.NamespaceDefinitionsTestCase.test_expr_dwo (lang/cpp/namespace_definitions/TestNamespaceDefinitions.py) FAIL: TestTopLevelExprs.TopLevelExpressionsTestCase.test_top_level_expressions_dwarf (expression_command/top-level/TestTopLevelExprs.py) FAIL: TestTopLevelExprs.TopLevelExpressionsTestCase.test_top_level_expressions_dwo (expression_command/top-level/TestTopLevelExprs.py) UNEXPECTED SUCCESS: TestExitDuringBreak.ExitDuringBreakpointTestCase.test_dwarf (functionalities/thread/exit_during_break/TestExitDuringBreak.py) UNEXPECTED SUCCESS: TestExitDuringBreak.ExitDuringBreakpointTestCase.test_dwo (functionalities/thread/exit_during_break/TestExitDuringBreak.py) UNEXPECTED SUCCESS: TestThreadStates.ThreadStateTestCase.test_process_interrupt_dwarf (functionalities/thread/state/TestThreadStates.py) UNEXPECTED SUCCESS: TestRaise.RaiseTestCase.test_restart_bug_dwarf (functionalities/signal/raise/TestRaise.py) UNEXPECTED SUCCESS: TestRaise.RaiseTestCase.test_restart_bug_dwo (functionalities/signal/raise/TestRaise.py) UNEXPECTED SUCCESS: TestMultithreaded.SBBreakpointCallbackCase.test_sb_api_listener_resume_dwarf (api/multithreaded/TestMultithreaded.py) UNEXPECTED SUCCESS: TestMultithreaded.SBBreakpointCallbackCase.test_sb_api_listener_resume_dwo (api/multithreaded/TestMultithreaded.py) UNEXPECTED SUCCESS: lldbsuite.test.lldbtest.TestPrintf.test_with_dwarf (lang/cpp/printf/TestPrintf.py) UNEXPECTED SUCCESS: lldbsuite.test.lldbtest.TestPrintf.test_with_dwo (lang/cpp/printf/TestPrintf.py) Well, at least the list is consistent, which gives me a base to start testing race conditions :-) On Wed, Apr 19, 2017 at 7:37 AM, Pavel Labath <lab...@google.com> wrote: > It is on purpose, although whether that purpose is worthwhile is > debatable... > > We chose to run release builds there so to align the bots closer to the > binaries we release. Unfortunately, it does mean we run into situations > like these... > > In any case, I have now a patch up for fixing one of the crashers. The > main one (assert during relocation processing) seems to be caused by a > recent change in llvm. I am working towards identifying the cause, but that > may take a while. > > Then we can hopefully have a look at failures on your machine. > > > On 19 April 2017 at 14:28, Scott Smith <scott.sm...@purestorage.com> > wrote: > >> Yeah I found the buildbot instance for lldb on Ubuntu 14.04, but it looks >> like it is only running release builds. Is that on purpose? >> >> On Wed, Apr 19, 2017 at 3:59 AM, Pavel Labath <lab...@google.com> wrote: >> >>> It looks like we are triggering an assert in llvm on a debug build. I'll >>> try to track this down ASAP. >>> >>> >>> On 18 April 2017 at 21:24, Scott Smith via lldb-dev < >>> lldb-dev@lists.llvm.org> wrote: >>> >>>> I'm trying to make sure some of my changes don't break lldb tests, but >>>> I'm having trouble getting a clean run even with a plain checkout. I've >>>> tried the latest head of master, as well as release_40. I'm running Ubuntu >>>> 16.04/amd64. I built with: >>>> >>>> cmake ../llvm -G Ninja -DCMAKE_BUILD_TYPE=Debug >>>> ninja lldb >>>> ninja check-lldb >>>> >>>> Compiler is gcc-5.4, though I've also tried with clang-4.0. >>>> >>>> Am I missing something obvious? Is there a docker image / vm image / >>>> known good environments that I can use to reproduce a clean test run (on >>>> something Linux-y - sorry, I don't have a Mac)? >>>> >>>> >>>> _______________________________________________ >>>> lldb-dev mailing list >>>> lldb-dev@lists.llvm.org >>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >>>> >>>> >>> >> >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
