In addition to flaky tests, I think some of these are just decorated
too broadly (e.g. it's marked expectedFailureLinux, but fails only on
i386 with gcc). I occasionally enable tests that I see are passing
consistently, but I am currently more worried about tests failing
unexpectedly than succeedin
> I don't recall exactly what it was off the top of my head, but I wonder
if Zachary needs that?
That is the lldb_enable_attach() call that I make in the beginning of the
inferior test driver, defined in
packages/Python/lldbsuite/test/make/test_common.h. This is already called,
so shouldn't be t
You also need to pass "hello, world" as a launch arg (in quotes). That is
what will make it get echoed back.
On Wed, Feb 3, 2016 at 8:05 PM, Todd Fiala wrote:
> Hey Zachary,
>
> For the test listed above, it is failing trying to match output from the
> inferior process being debugged by lldb-se
Hey Zachary,
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.
If you go in that directory and make/r
Yes, there is something like that but I am unable to recollect.
However, I do not think Zach's problem is that. He is able to get all
but 2 of the tests passing.
Zach, is it possible for you to run with clang-3.5?
On Wed, Feb 3, 2016 at 3:05 PM, Todd Fiala wrote:
> (Security around ptrace).
>
>
(Security around ptrace).
On Wed, Feb 3, 2016 at 3:04 PM, Todd Fiala wrote:
> Hmm I wonder if your lldb-server is able to attach to processes? Siva, we
> used to have some kind of kernel flag or something that would allow
> attaching to a process that was launched by something else. I don't re
Hmm I wonder if your lldb-server is able to attach to processes? Siva, we
used to have some kind of kernel flag or something that would allow
attaching to a process that was launched by something else. I don't recall
exactly what it was off the top of my head, but I wonder if Zachary needs
that?
In my logs I'm seeing this:
UNSUPPORTED: LLDB
(/usr/local/google_ssd/src/llvm/build/ninja_release/bin/clang-3.9-x86_64)
:: test_inferior_print_exit_debugserver_dwo
(TestLldbGdbServer.LldbGdbServerTestCase) (debugserver tests)
File
"/usr/local/google/home/zturner/ssd/src/llvm/tools/lldb/test/dote
We've occasionally discussed the concept of unexpected successes being an
issue. Last time we landed on this being the best we can do for now as we
want the code to be executed, even if it fails occasionally and/or under
load. The alternative (aside from fixing it) is to skip it, which then
preve
Our bot is running on Ubuntu 14.04 and is green:
http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake
One thing though, the bot does not run the testsuite with clang-3.6.
About the unexpected successes, they are very likely tests which were
found to be flaky and marked as expectedFailu
On Linux I get the following test results:
UNEXPECTED SUCCESS: test_and_run_command_dwarf
(lang/c/const_variables/TestConstVariables.py)
UNEXPECTED SUCCESS: test_and_run_command_dwo
(lang/c/const_variables/TestConstVariables.py)
UNEXPECTED SUCCESS: test_command_script_immediate_output_dwarf
(funct
11 matches
Mail list logo
