<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 19 April 2017 at 19:15, Scott Smith <span dir="ltr"><<a href="mailto:scott.smith@purestorage.com" target="_blank">scott.smith@purestorage.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div>A combination of:<br></div><div>1. Updating to a known good release according to buildbot<br></div>2. using Ubuntu 14.04<br></div>3. compiling release using clang-4.0<br></div></div></div></div></div></div></blockquote><div>I'd hope that the compiler used to build lldb does not matter. If you see any differences due to this factor, please let me know.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div></div><div>4. using the dotest command line that buildbot uses<br></div></div></div></div></div></div></blockquote><div>The exact command line the buildbot uses is not important.. The only important distinction from the check-lldb target is the compiler used. By default it uses the host compiler used to build lldb. As no-one builds tests using clang-4.0 it's quite possible that some things may be broken (or just not properly annotated).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div></div>5. specifying gcc-4.8 instead of the locally compiled clang<br><br></div>has most of the tests passing, with a handful of unexpected successes:<br><br>UNEXPECTED SUCCESS: TestRegisterVariables.<wbr>RegisterVariableTestCase.test_<wbr>and_run_command_dwarf (lang/c/register_variables/<wbr>TestRegisterVariables.py)<br>UNEXPECTED SUCCESS: TestRegisterVariables.<wbr>RegisterVariableTestCase.test_<wbr>and_run_command_dwo (lang/c/register_variables/<wbr>TestRegisterVariables.py)<br>UNEXPECTED SUCCESS: TestExitDuringBreak.<wbr>ExitDuringBreakpointTestCase.<wbr>test_dwarf (functionalities/thread/exit_<wbr>during_break/<wbr>TestExitDuringBreak.py)<br>UNEXPECTED SUCCESS: TestExitDuringBreak.<wbr>ExitDuringBreakpointTestCase.<wbr>test_dwo (functionalities/thread/exit_<wbr>during_break/<wbr>TestExitDuringBreak.py)<br>UNEXPECTED SUCCESS: TestThreadStates.<wbr>ThreadStateTestCase.test_<wbr>process_interrupt_dwarf (functionalities/thread/state/<wbr>TestThreadStates.py)<br>UNEXPECTED SUCCESS: TestThreadStates.<wbr>ThreadStateTestCase.test_<wbr>process_interrupt_dwo (functionalities/thread/state/<wbr>TestThreadStates.py)<br>UNEXPECTED SUCCESS: TestRaise.RaiseTestCase.test_<wbr>restart_bug_dwarf (functionalities/signal/raise/<wbr>TestRaise.py)<br>UNEXPECTED SUCCESS: TestRaise.RaiseTestCase.test_<wbr>restart_bug_dwo (functionalities/signal/raise/<wbr>TestRaise.py)<br>UNEXPECTED SUCCESS: TestMultithreaded.<wbr>SBBreakpointCallbackCase.test_<wbr>sb_api_listener_resume_dwarf (api/multithreaded/<wbr>TestMultithreaded.py)<br>UNEXPECTED SUCCESS: TestMultithreaded.<wbr>SBBreakpointCallbackCase.test_<wbr>sb_api_listener_resume_dwo (api/multithreaded/<wbr>TestMultithreaded.py)<br>UNEXPECTED SUCCESS: lldbsuite.test.lldbtest.<wbr>TestPrintf.test_with_dwarf (lang/cpp/printf/TestPrintf.<wbr>py)<br>UNEXPECTED SUCCESS: lldbsuite.test.lldbtest.<wbr>TestPrintf.test_with_dwo (lang/cpp/printf/TestPrintf.<wbr>py)<br></div></div></div></div></blockquote><div>The unexpected successes are expected, unfortunately. :) What happens here is that the tests are flaky and they fail like 1% of the time, so they are marked as xfail.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><br></div>This looks different than another user's issue: <a href="http://lists.llvm.org/pipermail/lldb-dev/2016-February/009504.html" target="_blank">http://lists.llvm.org/<wbr>pipermail/lldb-dev/2016-<wbr>February/009504.html</a><br><br></div>I also tried gcc-4.9.4 (via the ubuntu-toolchain-r ppa) and got a different set of problems:<br><br>FAIL: TestNamespaceDefinitions.<wbr>NamespaceDefinitionsTestCase.<wbr>test_expr_dwarf (lang/cpp/namespace_<wbr>definitions/<wbr>TestNamespaceDefinitions.py)<br>FAIL: TestNamespaceDefinitions.<wbr>NamespaceDefinitionsTestCase.<wbr>test_expr_dwo (lang/cpp/namespace_<wbr>definitions/<wbr>TestNamespaceDefinitions.py)<br>FAIL: TestTopLevelExprs.<wbr>TopLevelExpressionsTestCase.<wbr>test_top_level_expressions_<wbr>dwarf (expression_command/top-level/<wbr>TestTopLevelExprs.py)<br>FAIL: TestTopLevelExprs.<wbr>TopLevelExpressionsTestCase.<wbr>test_top_level_expressions_dwo (expression_command/top-level/<wbr>TestTopLevelExprs.py)<br>UNEXPECTED SUCCESS: TestExitDuringBreak.<wbr>ExitDuringBreakpointTestCase.<wbr>test_dwarf (functionalities/thread/exit_<wbr>during_break/<wbr>TestExitDuringBreak.py)<br>UNEXPECTED SUCCESS: TestExitDuringBreak.<wbr>ExitDuringBreakpointTestCase.<wbr>test_dwo (functionalities/thread/exit_<wbr>during_break/<wbr>TestExitDuringBreak.py)<br>UNEXPECTED SUCCESS: TestThreadStates.<wbr>ThreadStateTestCase.test_<wbr>process_interrupt_dwarf (functionalities/thread/state/<wbr>TestThreadStates.py)<br>UNEXPECTED SUCCESS: TestRaise.RaiseTestCase.test_<wbr>restart_bug_dwarf (functionalities/signal/raise/<wbr>TestRaise.py)<br>UNEXPECTED SUCCESS: TestRaise.RaiseTestCase.test_<wbr>restart_bug_dwo (functionalities/signal/raise/<wbr>TestRaise.py)<br>UNEXPECTED SUCCESS: TestMultithreaded.<wbr>SBBreakpointCallbackCase.test_<wbr>sb_api_listener_resume_dwarf (api/multithreaded/<wbr>TestMultithreaded.py)<br>UNEXPECTED SUCCESS: TestMultithreaded.<wbr>SBBreakpointCallbackCase.test_<wbr>sb_api_listener_resume_dwo (api/multithreaded/<wbr>TestMultithreaded.py)<br>UNEXPECTED SUCCESS: lldbsuite.test.lldbtest.<wbr>TestPrintf.test_with_dwarf (lang/cpp/printf/TestPrintf.<wbr>py)<br>UNEXPECTED SUCCESS: lldbsuite.test.lldbtest.<wbr>TestPrintf.test_with_dwo (lang/cpp/printf/TestPrintf.<wbr>py)<br><br></div>Well, at least the list is consistent, which gives me a base to start testing race conditions :-)<br></div></blockquote><div><br></div><div>Interesting, the bot uses a locally-built gcc-4.9.2 and those tests seem to work there... I'll see if I can find the time to check that out.</div><div><br></div><div>Could you please also share the list of failures when using the top-of-tree clang. I've tried that configuration yesterday on my home machine (x86_64 gentoo) and it had only a couple of failures -- most of them should be fixed now, only a single failure in TestExprs2 should remain that I am planning to have a look at.</div><div><br></div><div><br></div></div></div></div>