Change `self.build(...)` to assert if called with arguments of any kind,
for tests which have `SHARED_BUILD_TESTCASE` enabled (the default).
This also changes all tests that began asserting with this change, tests
which call `self.build(...)` with arguments.
---------
Co-authored-by: Adrian Prantl <adrian.prantl@gmail.com>
I did manage to turn a crash into a non-zero return code,
but on the very first build it managed to time out.
I thought I had the appetite to tweak timeouts but
on second thought, I don't want yet another test to look
out for.
The test is not wrong, but on heavily loaded machines
it's always going to be inherently unstable.
Fixes#101162
This test did this:
* SBDebugger::Initialize
* Spawn a bunch of threads that do:
* SBDebugger::Create
* some work
* SBDebugger::Destroy
* Wait on those threads to finish then call SBDebugger::Terminate and
exit, or -
* Reach a time limit before all the threads finish, call
SBDebugger::Terminate and exit.
The problem was that in the timeout case, calling SBDebugger::Terminate
destroys data being used by threads that are still running. I expect
this test was expecting said threads to be so broken they were probably
stuck, but when the machine is just heavily loaded, one of them might
read that data before the whole program exits.
This means what should have been a timeout becomes a crash. Sometimes.
Which explains why we saw both timeouts and various signals on the
AArch64 Linux bot. It depends on the timings.
So I'm changing it not to call SBDebugger::Terminate in the timeout
case. We will have to tweak the timeout value based on what happens on
the buildbot, but we will know it's machine load not an lldb bug.
Also use _exit instead of exit, to skip more cleanup that might cause a
crash.
This test has been flaky lately
(https://github.com/llvm/llvm-project/issues/101162) and I disabled it
everywhere initially.
I found that it always uses "x86_64" for the program architecture so the
test was "passing" elsewhere but I don't think it was meant to. So I
have added a define to pass on the host's architecture when compiling.
This makes it work on AArch64 as well.
While I'm here I've fixed the uint64_t formatting warnings by using the
defined formats that'll work everywhere.
In addition, I found that the function names include "()" on Linux, so
now we check for "foo" or "foo()".
The test cpp file has never been, or was only partially formatted so
I've not formatted the changes, just kept to the local style.
I've removed the Linux skip to see if any of this helps the timeouts,
and to verify the build command changes. If the timeouts come back I'll
disable it again.
This test occasionally fails on two of the busiest CI bots (asan and
matrix), and we can't reproduce it locally. This leads to the
hypothesis that the test is timing out (in the sense of the number of
"join attempts" performed by this test's driver).
This commit doubles the number of iterations performed and also does
an NFC refactor of the main test loop so that it can be more easily
understood.
We have a handful of tests that build a driver which links against LLDB.
When running those binaries, we overwrite the dynamic loader library
path to point to the build directory's libs dir, presumably to make sure
we load LLDB from there.
This above becomes an issue when you have libc++ enabled and the driver
is linked against the system's libc++, but the dynamic loader flag
forces it to pick up libc++ from the libs dir.
We could try to make the logic for building the driver smarter and have
it pick up the just-built libc++ like we do for our test binaries, but I
don't think we need to overwrite the library path in the first place.
The build logic to build these drivers already takes care to set the
correct RPATH in the linker.
This patch removes the logic and simplifies the tests.
Fix and rename the broken and confusingly named decorator
skipIfHostIncompatibleWithRemote. The decorator is meant to skip test
which uses the inferior test build system (i.e. to build test inferiors)
to build host binaries (e.g. lldb drivers).
The decorator was broken on macOS, where the host and target platform
report macosx, but the decorator overwrote it with Darwin, resulting in
tests incorrectly being skipped.
The decorator was also missing on a handful of tests that use the
buildDriver helper, which this commit fixes as well.
This is an ongoing series of commits that are reformatting our Python
code. Reformatting is done with `black` (23.1.0).
If you end up having problems merging this commit because you have made
changes to a python file, the best way to handle that is to run `git
checkout --ours <yourfile>` and then reformat it with black.
RFC: https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style
Differential revision: https://reviews.llvm.org/D151460
In situations where only LLDB is ASANified, a false positive occurs
unless ASAN_OPTIONS=detect_container_overflow=0 is set in the
environment.
Differential Revision: https://reviews.llvm.org/D143772
Eliminate boilerplate of having each test manually assign to `mydir` by calling
`compute_mydir` in lldbtest.py.
Differential Revision: https://reviews.llvm.org/D128077
Make category-specifying files visible. There is really no good reason
to keep them hidden, and having them visible increases the chances
that someone will actually spot them.
Differential Revision: https://reviews.llvm.org/D91065
The new FreeBSDRemote plugin has reached feature parity on i386
and amd64 targets. Use it by default on these architectures, while
allowing the use of the legacy plugin via FREEBSD_LEGACY_PLUGIN envvar.
Revisit the method of switching plugins. Apparently, the return value
of PlatformFreeBSD::CanDebugProcess() is what really decides whether
the legacy or the new plugin is used.
Update the test status. Reenable the tests that were previously
disabled on FreeBSD and do not cause hangs or are irrelevant to FreeBSD.
Mark all tests that fail reliably as expectedFailure. For now, tests
that are flaky (i.e. produce unstable results) are left enabled
and cause unpredictable test failures.
Differential Revision: https://reviews.llvm.org/D90757
The comment says that TestMultipleDebuggers was XFAILed because it was
failing nondeterministically in which case it should be skipped not
failed (as XPASS will cause the test suite to fail).
The reason it fails is because it was not marked as a no-debug-info test
case. I've ran the test in a loop and it has been passing consistently.
Let's enable it and see if the bots agree, if not we can skip it.
Summary: Moves lldbsuite tests to lldb/test/API.
This is a largely mechanical change, moved with the following steps:
```
rm lldb/test/API/testcases
mkdir -p lldb/test/API/{test_runner/test,tools/lldb-{server,vscode}}
mv lldb/packages/Python/lldbsuite/test/test_runner/test lldb/test/API/test_runner
for d in $(find lldb/packages/Python/lldbsuite/test/* -maxdepth 0 -type d | egrep -v "make|plugins|test_runner|tools"); do mv $d lldb/test/API; done
for d in $(find lldb/packages/Python/lldbsuite/test/tools/lldb-vscode -maxdepth 1 -mindepth 1 | grep -v ".py"); do mv $d lldb/test/API/tools/lldb-vscode; done
for d in $(find lldb/packages/Python/lldbsuite/test/tools/lldb-server -maxdepth 1 -mindepth 1 | egrep -v "gdbremote_testcase.py|lldbgdbserverutils.py|socket_packet_pump.py"); do mv $d lldb/test/API/tools/lldb-server; done
```
lldb/packages/Python/lldbsuite/__init__.py and lldb/test/API/lit.cfg.py were also updated with the new directory structure.
Reviewers: labath, JDevlieghere
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71151
