[lldb-dev] Running check-lldb

Wed Apr 19 11:15:27 PDT 2017

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 <labath at 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.smith at 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 <labath at 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 at 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 at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20170419/3796b378/attachment-0001.html>