| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Previously each test was annotated manually. This does the same thing.
|
| |
|
|
| |
The is the best method we have at the moment for attach-style tests.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
that don't actually call 'print()'
Summary:
A lot of tests do this trick but the vast majority of them don't even call `print()`.
Most of this patch was generated by a script that just looks at all the files and deletes the line if there is no `print (` or `print(` anywhere else in the file.
I checked the remaining tests manually and deleted the import if we never call print (but instead do stuff like `expr print(...)` and similar false-positives).
I also corrected the additional empty lines after the import in the files that I manually edited.
Reviewers: JDevlieghere, labath, jfb
Reviewed By: labath
Subscribers: dexonsmith, wuzish, nemanjai, kbarton, christof, arphaman, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71452
|
| |
|
|
|
|
|
|
|
|
|
|
| |
mandatory in StackTraces response for VSCode extension that implements DAP and declares capability 'supportsDelayedStackTraceLoading':
"The debug adapter supports the delayed loading of parts of the stack,
which requires that both the 'startFrame' and 'levels' arguments and the
'totalFrames' result of the 'StackTrace' request are supported."
Lack of this field makes VSCode incorrectly display stack traces information
D71034
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The test used a non-stopping "run" command to launch the process. This
is different from the regular launch with no extra launch commands,
which uses eLaunchFlagStopAtEntry to ensure that the process stops
straight away.
I'm not really sure what's supposed to happen in non-stop-at-entry mode,
or if that's even supported, but what ended up happening was the launch
packet got a reply while the process was running. Then the test case did
a continue_to_next_stop(), which queued a *second* resume request
(along with the internal "resumes" which were being issued as a part of
normal process startup). These two resumes ended up chasing each other's
tails inside lldb in a way which produced hilarious log traces.
Surprisingly, the test ended up passing most of the time, but it did
cause spurious failures when the test seemed to miss a breakpoint.
This changes the test to use stop-at-entry mode in the manual launch
sequence too, which seems to be enough to make the test pass reliably.
Reviewers: clayborg, kusmour, jankratochvil
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70127
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The DAP has a completion request that has been unimplemented. It allows showing autocompletion tokens inside the Debug Console.
I implemented it in a very simple fashion mimicking what the user would see when autocompleting an expression inside the CLI.
There are two cases: normal variables and commands. The latter occurs when a text is prepepended with ` in the Debug Console.
These two cases work well and have tests.
Reviewers: clayborg, aadsm
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D69873
|
| |
|
|
|
|
|
| |
The VSCode tests were all disabled on macOS because the implementation
had some issues that resulted in flakiness on Darwin. It seems most of
these issues have been addressed. I've re-enabled all the tests that
consistently passed locally.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In r367234 we introduced a central place to hold the set up commands for
the various ways we have of launching lldb. However, a number of
commands still remained outside of that.
This patch moves the remaining set up commands into this function, which
allows us to remove manual clang module path setting code in
TestBatchMode.
One unfortunate victim of this approach is TestSTTYBeforeAndAfter which,
due to how it launches lldb (pexpect->expect->lldb), fails get the
quoting right. It would be possible to fix the quoting there, it would be a bit
icky, and none of the commands in this list are really relevant for what this
test is doing, so I just remove the commands outright.
Reviewers: JDevlieghere, jankratochvil
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D67173
llvm-svn: 371019
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Instead of each test case knowing its depth relative to the test root,
we can just have dotest add the folder containing Makefile.rules to the
include path.
This was motivated by r370616, though I have been wanting to do this
ever since we moved to building tests out-of-tree.
The only manually modified files in this patch are lldbinline.py and
plugins/builder_base.py. The rest of the patch has been produced by this
shell command:
find . \( -name Makefile -o -name '*.mk' \) -exec sed --in-place -e '/LEVEL *:\?=/d' -e '1,2{/^$/d}' -e 's,\$(LEVEL)/,,' {} +
Reviewers: teemperor, aprantl, espindola, jfb
Subscribers: emaste, javed.absar, arichardson, christof, arphaman, lldb-commits
Differential Revision: https://reviews.llvm.org/D67083
llvm-svn: 370845
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 367663
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
Replace os.path.split()[0] with os.path.dirname(). Suggested by Pavel
Labath in D65432.
llvm-svn: 367290
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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: This was removed here rL366590 by accident.
Reviewers: xiaobai, jfb
Reviewed By: xiaobai
Subscribers: dexonsmith, srhines, krytarowski, jfb, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D65123
llvm-svn: 366766
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
testcases
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
|
| |
|
|
| |
llvm-svn: 358660
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
Test hangs under heavy load.
llvm-svn: 356379
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: lldb-commits
Subscribers: srhines, ki.stfu
Differential Revision: https://reviews.llvm.org/D52884
llvm-svn: 343825
|
| |
|
|
| |
llvm-svn: 341186
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
load and poor machines.
llvm-svn: 340112
|
| |
|
|
|
|
| |
having trouble.
llvm-svn: 340077
|
| |
|
|
|
|
|
|
| |
on what is going wrong on test bots.
Also add a cleanup function to remove the copied binary.
llvm-svn: 340050
|
|
|
Debug Adaptor Protocol
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
|
