Summary:
This can help `lldb-vscode` handle launch commands associate with remote platform
attach request have field `attachCommands` to handle attach specific commands
add a corresponding one for launch request
if no launch command is provided, create a new target and launch; otherwise, execute the launch command
Differential Revision: https://reviews.llvm.org/D65363
Patch by Wanyi Ye <kusmour@gmail.com>
llvm-svn: 369296
Compare the directory paths returned by lldb-vscode against realpaths
rather than apparent paths. This matches lldb-vscode behavior
and therefore fixes test failures when one of the parent directories
of the source tree is a symlink.
Differential Revision: https://reviews.llvm.org/D65432
llvm-svn: 367291
rL357954 did increase `packet-timeout` 1sec -> 5secs. Which is IMO about the
maximum timeout reasonable for regular use. But for testsuite I think the
timeout should be higher as the testsuite runs in parallel and it can be run
even on slow hosts and with other load (moreover if it runs on some slow arch).
I have chosen 60 secs, that should be enough hopefully. Larger value could
make debugging with hanging `lldb-server` annoying.
This patch was based on this testsuite timeout:
http://lab.llvm.org:8014/builders/lldb-x86_64-fedora/builds/546/steps/test/logs/stdio
FAIL: test_connect (TestGDBRemoteClient.TestGDBRemoteClient)
Test connecting to a remote gdb server
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/jkratoch/slave-lldb-x86_64-fedora/lldb-x86_64-fedora/llvm/tools/lldb/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestGDBRemoteClient.py", line 13, in test_connect
process = self.connect(target)
File "/home/jkratoch/slave-lldb-x86_64-fedora/lldb-x86_64-fedora/llvm/tools/lldb/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/gdbclientutils.py", line 480, in connect
self.assertTrue(error.Success(), error.description)
AssertionError: False is not True : failed to get reply to handshake packet
Differential Revision: https://reviews.llvm.org/D65271
llvm-svn: 367234
Mark the process as stopped when SIGSTOP arrives. This is necessary
for lldb-server to generate correct response to 'process interrupt',
and therefore to prevent the whole stack crashing when process
is stopped.
Thanks to Pavel Labath for the tip.
Differential Revision: https://reviews.llvm.org/D65289
llvm-svn: 367047
On slower machines the vscode testcases were sometimes hanging:
1910 ? Sl 0:00 | \_ /usr/bin/python .../llvm/tools/lldb/test/dotest.py ... -p TestVSCode_setBreakpoints.py
2649 ? Sl 0:00 | \_ .../build/bin/lldb-vscode
2690 ? S 0:00 | \_ .../build/bin/lldb-server gdbserver --fd=9 --native-regs --setsid
2708 ? t 0:00 | \_ .../build/lldb-test-build.noindex/tools/lldb-vscode/breakpoint/TestVSCode_setBreakpoints.test_functionality/a.out
A reproducer of the racy bug for send_recv():
# self.send_packet(command)
#+ import time
#+ time.sleep(1)
# done = False
I guess `request_continue` was probably originally intended to be synchronous
but then it isn't and this code has been leftover there.
Differential revision: https://reviews.llvm.org/D65163
llvm-svn: 366850
Summary: lldb-mi has been removed, but there are still a bunch of references in the code base. This patch removes all of them.
Reviewers: JDevlieghere, jfb
Reviewed By: JDevlieghere
Subscribers: dexonsmith, ki.stfu, mgorny, abidh, jfb, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64992
llvm-svn: 366590
D55859 <https://reviews.llvm.org/D55859> has no effect for some of the
testcases so this patch extends it even for (all?) other testcases known to me.
LLDB was failing when LLDB prints errors reading system debug infos
(`*-debuginfo.rpm`, DWZ-optimized) which should never happen as LLDB testcases
should not be affected by system debug infos.
`lldb/packages/Python/lldbsuite/test/api/multithreaded/driver.cpp.template` is
using only SB API which does not expose `ModuleList` so I had to call
`HandleCommand()` there.
`lldb-test.cpp` could also use `HandleCommand` and then there would be no need
for `ModuleListProperties::SetEnableExternalLookup()` but I think it is cleaner
with API and not on based on text commands.
Differential Revision: https://reviews.llvm.org/D63339
llvm-svn: 363567
The test is failing sometimes because the debugger is failing to attach for lack of permissions. The fix is to call lldb_enable_attach inside the inferior main function
llvm-svn: 360371
Summary:
The test was failing occasionally (1% of runs or so), because of
unpredictable timings between the two threads spawned by the test. If
the second thread hit the breakpoint right as we were stepping out of
the function on the first thread, we would still be stuck at the inner
frame when the process stopped.
This would cause errors like:
File "/home/worker/lldb-x86_64-debian/lldb-x86_64-debian/llvm/tools/lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/step/TestVSCode_step.py", line 67, in test_step
self.assertEqual(x1, x3, 'verify step out variable')
AssertionError: 2 != 1 : verify step out variable
AFAICT, lldb-vscode is doing the right thing here, and the problem is
that the test is not taking this sequence of events into account. Since
the test is about testing stepping, it does not seem necessary to have
threads in the inferior at all, so I just rewrite the test to execute
the code we're supposed to step through directly on the main thread.
Reviewers: clayborg, jgorbe
Subscribers: jfb, lldb-commits
Differential Revision: https://reviews.llvm.org/D60608
llvm-svn: 358847
When this test fails (flakes) all we get is an error message like "False
is not True". This replaces patterns like assertTrue(a == b) with
assertEqual(a, b), so we get a better error message (and hopefully a
hint as to why the test is flaky).
llvm-svn: 357747
Summary:
After https://reviews.llvm.org/D59828 and https://reviews.llvm.org/D59849,
I believe the problems with these tests hanging have been solved.
I tried enabling all of them on my machine, and got two failures:
- One of them was spawning a child process that lives for 5 seconds, waited
for 5 seconds to attach to the child, and failed because the child wasn't
there.
- The other one was a legit failure because shell expansion of arguments doesn't
work on Linux.
This tests enables all lldb-vscode tests on Linux except for "launch process
with shell expansion of args" (which doesn't work), and fixes the other broken
test by reducing the time it waits before attaching to its child process.
Reviewers: zturner, clayborg
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D60153
llvm-svn: 357633
Summary:
This change prevents the lldb-vscode test harness from hanging up waiting for
new messages when the lldb-vscode subprocess crashes.
Now, when an EOF from the subprocess pipe is detected we enqueue a `None` packet
in the received packets list. Then, during the message processing loop, we can
use this `None` packet to tell apart the case where lldb-vscode has terminated
unexpectedly from the normal situation where no pending messages means blocking
and waiting for more data.
I believe this should be enough to fix the issues with these tests hanging on
multiple platforms. Once this lands, I'll prepare and test a separate change
removing the @skipIfLinux annotations.
Reviewers: clayborg, zturner
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D59849
llvm-svn: 357426
Add a convenience 'expectedFailureNetBSD' decorator and mark all tests
currently failing on NetBSD with it. Also skip a few tests that hang
the test suite. This should establish a baseline for the test suite
and get us closer to enabling tests on buildbot. This will help us
catch regressions while we still have a lot of work to do to get tests
working.
It seems that there are also some flaky tests. I am going to address
them later on.
Differential Revision: https://reviews.llvm.org/D58527
llvm-svn: 355320
encode/decode the data before sending it over the socket. Since (AFAICT)
the vscode protocol (unlike the gdb-remote one) is fully textual, using
the utf8 codec here is appropriate.
llvm-svn: 354308
Summary: These are already skipped on Darwin because they cause build bot failures. Both on the build bots as well as in our testing we have seen a number of these tests fail and hang. This change skips the failing/hanging tests on Linux and also fixes one of the test - the test needs the thread library to build.
Reviewers: asmith, clayborg, aprantl
Subscribers: teemperor, lldb-commits
Differential Revision: https://reviews.llvm.org/D51227
llvm-svn: 340658
This patch adds a new lldb-vscode tool that speaks the Microsoft Visual Studio Code debug adaptor protocol. It has full unit tests that test all packets.
This tool can be easily packaged up into a native extension and used with Visual Studio Code, and it can also be used by Nuclide
Differential Revision: https://reviews.llvm.org/D50365
llvm-svn: 339911
