<div dir="ltr">Hey Zachary,<div><br></div><div>For the test listed above, it is failing trying to match output from the inferior process being debugged by lldb-server. First, it is trying to get a hello, world string to be printed. Then, it is expecting the process to exit without failure.</div><div><br></div><div>If you go in that directory and make/run the a.out program, it should print hello world and exit with an exit value of 0. You may find that it doesn't print, perhaps? Or maybe your terminal is set differently, so that the text isn't matching as expected? (I would expect to have heard others with this issue).</div><div><br></div><div>Pavel just added some gdb remote logging that is easier to access than the way I had it rigged up before. If you end up getting stuck, if you get the output log from either the lldb-server side, that would probably help figure out what's getting stuck. But I wouldn't bother with that if you can rule out that something with the a.out is going wrong first.</div><div><br></div><div>-Todd</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 3, 2016 at 3:16 PM, Siva Chandra <span dir="ltr"><<a href="mailto:sivachandra@google.com" target="_blank">sivachandra@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Yes, there is something like that but I am unable to recollect.<br>
However, I do not think Zach's problem is that. He is able to get all<br>
but 2 of the tests passing.<br>
<br>
Zach, is it possible for you to run with clang-3.5?<br>
<div class="HOEnZb"><div class="h5"><br>
On Wed, Feb 3, 2016 at 3:05 PM, Todd Fiala <<a href="mailto:todd.fiala@gmail.com">todd.fiala@gmail.com</a>> wrote:<br>
> (Security around ptrace).<br>
><br>
> On Wed, Feb 3, 2016 at 3:04 PM, Todd Fiala <<a href="mailto:todd.fiala@gmail.com">todd.fiala@gmail.com</a>> wrote:<br>
>><br>
>> Hmm I wonder if your lldb-server is able to attach to processes? Siva, we<br>
>> used to have some kind of kernel flag or something that would allow<br>
>> attaching to a process that was launched by something else. I don't recall<br>
>> exactly what it was off the top of my head, but I wonder if Zachary needs<br>
>> that?<br>
>><br>
>> -Todd<br>
>><br>
>> On Wed, Feb 3, 2016 at 3:02 PM, Zachary Turner via lldb-dev<br>
>> <<a href="mailto:lldb-dev@lists.llvm.org">lldb-dev@lists.llvm.org</a>> wrote:<br>
>>><br>
>>> In my logs I'm seeing this:<br>
>>><br>
>>> UNSUPPORTED: LLDB<br>
>>> (/usr/local/google_ssd/src/llvm/build/ninja_release/bin/clang-3.9-x86_64) ::<br>
>>> test_inferior_print_exit_debugserver_dwo<br>
>>> (TestLldbGdbServer.LldbGdbServerTestCase) (debugserver tests)<br>
>>> File<br>
>>> "/usr/local/google/home/zturner/ssd/src/llvm/tools/lldb/test/dotest.py",<br>
>>> line 7, in <module><br>
>>> lldbsuite.test.run_suite()<br>
>>> File<br>
>>> "/usr/local/google_ssd/src/llvm/tools/lldb/packages/Python/lldbsuite/test/dotest.py",<br>
>>> line 1089, in run_suite<br>
>>> resultclass=test_result.LLDBTestResult).run(configuration.suite)<br>
>>> File<br>
>>> "/usr/local/google_ssd/src/llvm/tools/lldb/third_party/Python/module/unittest2/unittest2/runner.py",<br>
>>> line 162, in run<br>
>>> test(result)<br>
>>> File<br>
>>> "/usr/local/google_ssd/src/llvm/tools/lldb/third_party/Python/module/unittest2/unittest2/suite.py",<br>
>>> line 65, in __call__<br>
>>> return self.run(*args, **kwds)<br>
>>> File<br>
>>> "/usr/local/google_ssd/src/llvm/tools/lldb/third_party/Python/module/unittest2/unittest2/suite.py",<br>
>>> line 85, in run<br>
>>> self._wrapped_run(result)<br>
>>> File<br>
>>> "/usr/local/google_ssd/src/llvm/tools/lldb/third_party/Python/module/unittest2/unittest2/suite.py",<br>
>>> line 115, in _wrapped_run<br>
>>> test._wrapped_run(result, debug)<br>
>>> File<br>
>>> "/usr/local/google_ssd/src/llvm/tools/lldb/third_party/Python/module/unittest2/unittest2/suite.py",<br>
>>> line 117, in _wrapped_run<br>
>>> test(result)<br>
>>> File<br>
>>> "/usr/local/google_ssd/src/llvm/tools/lldb/third_party/Python/module/unittest2/unittest2/case.py",<br>
>>> line 433, in __call__<br>
>>> return self.run(*args, **kwds)<br>
>>> File<br>
>>> "/usr/local/google_ssd/src/llvm/tools/lldb/third_party/Python/module/unittest2/unittest2/case.py",<br>
>>> line 361, in run<br>
>>> success = self.runMethod(testMethod, result)<br>
>>> File<br>
>>> "/usr/local/google_ssd/src/llvm/tools/lldb/third_party/Python/module/unittest2/unittest2/case.py",<br>
>>> line 391, in runMethod<br>
>>> testMethod()<br>
>>> File<br>
>>> "/usr/local/google_ssd/src/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py",<br>
>>> line 1900, in dwarf_test_method<br>
>>> return attrvalue(self)<br>
>>> File<br>
>>> "/usr/local/google_ssd/src/llvm/tools/lldb/packages/Python/lldbsuite/test/decorators.py",<br>
>>> line 112, in wrapper<br>
>>> func(*args, **kwargs)<br>
>>> File<br>
>>> "/usr/local/google_ssd/src/llvm/tools/lldb/packages/Python/lldbsuite/test/tools/lldb-server/TestLldbGdbServer.py",<br>
>>> line 250, in test_inferior_print_exit_llgs<br>
>>> self.inferior_print_exit()<br>
>>> File<br>
>>> "/usr/local/google_ssd/src/llvm/tools/lldb/packages/Python/lldbsuite/test/tools/lldb-server/TestLldbGdbServer.py",<br>
>>> line 237, in inferior_print_exit<br>
>>> context = self.expect_gdbremote_sequence()<br>
>>> File<br>
>>> "/usr/local/google_ssd/src/llvm/tools/lldb/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py",<br>
>>> line 549, in expect_gdbremote_sequence<br>
>>> return expect_lldb_gdbserver_replay(self, self.sock,<br>
>>> self.test_sequence, timeout_seconds, self.logger)<br>
>>> File<br>
>>> "/usr/local/google_ssd/src/llvm/tools/lldb/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py",<br>
>>> line 252, in expect_lldb_gdbserver_replay<br>
>>> context["O_content"] = pump.get_accumulated_output()<br>
>>> File<br>
>>> "/usr/local/google_ssd/src/llvm/tools/lldb/packages/Python/lldbsuite/test/tools/lldb-server/socket_packet_pump.py",<br>
>>> line 81, in __exit__<br>
>>> traceback.print_stack()<br>
>>> lldb-server exiting...<br>
>>><br>
>>> Could this be related to the timeout I'm seeing? Has anyone seen this<br>
>>> before? It doesn't appear flaky, happens every time.<br>
>>><br>
>>> On Wed, Feb 3, 2016 at 2:57 PM Siva Chandra <<a href="mailto:sivachandra@google.com">sivachandra@google.com</a>><br>
>>> wrote:<br>
>>>><br>
>>>> Our bot is running on Ubuntu 14.04 and is green:<br>
>>>> <a href="http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake" rel="noreferrer" target="_blank">http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake</a><br>
>>>><br>
>>>> One thing though, the bot does not run the testsuite with clang-3.6.<br>
>>>> About the unexpected successes, they are very likely tests which were<br>
>>>> found to be flaky and marked as expectedFailure (or something similar)<br>
>>>> to keep the bot green. Even the bot logs show these unexpected<br>
>>>> successes.<br>
>>>><br>
>>>> On Wed, Feb 3, 2016 at 2:50 PM, Zachary Turner via lldb-dev<br>
>>>> <<a href="mailto:lldb-dev@lists.llvm.org">lldb-dev@lists.llvm.org</a>> wrote:<br>
>>>> ><br>
>>>> > On Linux I get the following test results:<br>
>>>> ><br>
>>>> > UNEXPECTED SUCCESS: test_and_run_command_dwarf<br>
>>>> > (lang/c/const_variables/TestConstVariables.py)<br>
>>>> > UNEXPECTED SUCCESS: test_and_run_command_dwo<br>
>>>> > (lang/c/const_variables/TestConstVariables.py)<br>
>>>> > UNEXPECTED SUCCESS: test_command_script_immediate_output_dwarf<br>
>>>> ><br>
>>>> > (functionalities/command_script_immediate_output/TestCommandScriptImmediateOutput.py)<br>
>>>> > UNEXPECTED SUCCESS: test_command_script_immediate_output_dwo<br>
>>>> ><br>
>>>> > (functionalities/command_script_immediate_output/TestCommandScriptImmediateOutput.py)<br>
>>>> > UNEXPECTED SUCCESS: test_fd_leak_basic_dwarf<br>
>>>> > (functionalities/avoids-fd-leak/TestFdLeak.py)<br>
>>>> > UNEXPECTED SUCCESS: test_fd_leak_basic_dwo<br>
>>>> > (functionalities/avoids-fd-leak/TestFdLeak.py)<br>
>>>> > UNEXPECTED SUCCESS: test_fd_leak_log_dwarf<br>
>>>> > (functionalities/avoids-fd-leak/TestFdLeak.py)<br>
>>>> > UNEXPECTED SUCCESS: test_fd_leak_log_dwo<br>
>>>> > (functionalities/avoids-fd-leak/TestFdLeak.py)<br>
>>>> > UNEXPECTED SUCCESS: test_fd_leak_multitarget_dwarf<br>
>>>> > (functionalities/avoids-fd-leak/TestFdLeak.py)<br>
>>>> > UNEXPECTED SUCCESS: test_fd_leak_multitarget_dwo<br>
>>>> > (functionalities/avoids-fd-leak/TestFdLeak.py)<br>
>>>> > UNEXPECTED SUCCESS: test_file_scope_lookup_with_run_command_dwarf<br>
>>>> > (lang/cpp/namespace/TestNamespaceLookup.py)<br>
>>>> > UNEXPECTED SUCCESS: test_file_scope_lookup_with_run_command_dwo<br>
>>>> > (lang/cpp/namespace/TestNamespaceLookup.py)<br>
>>>> > UNEXPECTED SUCCESS: test_lldbmi_gdb_set_target_async_off<br>
>>>> > (tools/lldb-mi/TestMiGdbSetShow.py)<br>
>>>> > UNEXPECTED SUCCESS: test_lldbmi_process_output<br>
>>>> > (tools/lldb-mi/syntax/TestMiSyntax.py)<br>
>>>> > UNEXPECTED SUCCESS: test_lldbmi_settings_set_target_run_args_after<br>
>>>> > (tools/lldb-mi/interpreter/TestMiInterpreterExec.py)<br>
>>>> > UNEXPECTED SUCCESS: test_lldbmi_settings_set_target_run_args_before<br>
>>>> > (tools/lldb-mi/interpreter/TestMiInterpreterExec.py)<br>
>>>> > UNEXPECTED SUCCESS: test_restart_bug_dwarf<br>
>>>> > (functionalities/signal/raise/TestRaise.py)<br>
>>>> > UNEXPECTED SUCCESS: test_restart_bug_dwo<br>
>>>> > (functionalities/signal/raise/TestRaise.py)<br>
>>>> > UNEXPECTED SUCCESS:<br>
>>>> > test_scope_lookup_before_using_with_run_command_dwo<br>
>>>> > (lang/cpp/namespace/TestNamespaceLookup.py)<br>
>>>> > TIMEOUT: test_qThreadInfo_matches_qC_attach_llgs_dwo<br>
>>>> > (tools/lldb-server/TestLldbGdbServer.py)<br>
>>>> > TIMEOUT: test_watchpoint_delay_watchpoint_one_breakpoint_dwarf<br>
>>>> > (functionalities/thread/concurrent_events/TestConcurrentEvents.py)<br>
>>>> ><br>
>>>> ><br>
>>>> > This is a ton of unexpected successes. Does anyone regularly run the<br>
>>>> > test<br>
>>>> > suite on Linux? Is this normal? I also notice that it takes almost<br>
>>>> > 30<br>
>>>> > minutes to complete, and I get these timeouts:<br>
>>>> ><br>
>>>> > TIMEOUT: test_qThreadInfo_matches_qC_attach_llgs_dwo<br>
>>>> > (tools/lldb-server/TestLldbGdbServer.py)<br>
>>>> > TIMEOUT: test_watchpoint_delay_watchpoint_one_breakpoint_dwarf<br>
>>>> > (functionalities/thread/concurrent_events/TestConcurrentEvents.py)<br>
>>>> ><br>
>>>> > Are these known issues? I'm using Ubuntu 14.04 and building tests<br>
>>>> > with<br>
>>>> > Clang 3.6<br>
>>>> ><br>
>>>> > _______________________________________________<br>
>>>> > lldb-dev mailing list<br>
>>>> > <a href="mailto:lldb-dev@lists.llvm.org">lldb-dev@lists.llvm.org</a><br>
>>>> > <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br>
>>>> ><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> lldb-dev mailing list<br>
>>> <a href="mailto:lldb-dev@lists.llvm.org">lldb-dev@lists.llvm.org</a><br>
>>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br>
>>><br>
>><br>
>><br>
>><br>
>> --<br>
>> -Todd<br>
><br>
><br>
><br>
><br>
> --<br>
> -Todd<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">-Todd</div></div>
</div>