On Wednesday, February 03, 2016 05:15 AM, Hans Wennborg via
Release-testers wrote:
Dear testers,
Release Candidate 2 has just been tagged [1]. Please build, test, and
upload to the sftp.
clang+llvm-3.8.0-rc2-x86_64-linux-gnu-ubuntu-14.04.tar.xz:
Failing Tests (9):
MemorySanitizer :: Linux
On 2 February 2016 at 21:15, Hans Wennborg via lldb-dev
wrote:
> Dear testers,
>
> Release Candidate 2 has just been tagged [1]. Please build, test, and
> upload to the sftp.
ARM and AArch64 look good, uploaded. I'm not using any new distro, so
all the ABI issues are not showing, but they do exi
https://llvm.org/bugs/show_bug.cgi?id=26441
Jim Ingham changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
When I use SBDebugger::SetAsync(true), the process is not stopped at scanf,
so it does not wait for input. The process does stop and wait for input
when SetAsync(false). Unfortunately, when building a GUI on top of the C++
API, I have to SetAsync(true).
Is there some way to resolve this?
Thanks
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
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
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
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
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?
(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
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).
>
>
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
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
> 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
Hi,
I found that if I am using synchronous mode, some times there are no debug
events generated during launch. For example, for the code
below, LLDBListenerThread will receive no debug events.
Is this expected? What is the rule of debug events in synchronous mode?
def main():
debugger = lldb
15 matches
Mail list logo
