Patterns in the top-level .gitignore match in all subdirectories, so
there's no need to repeat ourselves quite so much for generic
C, Autotools and gcov patterns.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This means we don't need to distinguish between DBUS_NAME_TEST_EXEC and
DBUS_TEST_EXEC any more, because all test helper executables are in the
same place, both during build and when installed (we don't install
test-privserver since no installed test requires it yet, but in
principle we could).
Signed-off-by: Simon McVittie <smcv@collabora.com>
I've assumed that trivial changes from Scott James Remnant (correcting
some bus names) and Marcus Brinkmann (adding a <config.h> include
tree-wide) are not significant here. All the other potential copyright
holders from the git log are listed, and all have given permission to
relicense their dbus contributions under the MIT/X11 license.
Signed-off-by: Simon McVittie <smcv@collabora.com>
We don't want to set these globally via the normal CFLAGS, because if
we did, AddressSanitizer would catch test-segfault deliberately
segfaulting, and "helpfully" turn it into exit status 1, which in turn
makes our test fail because it asserts that the segfault is reported
as a segfault.
A typical use with gcc as compiler, on a reasonably recent Debian,
would be:
./configure SANITIZE_CFLAGS="-fsanitize=address -fsanitize=undefined -fPIE -pie"
Signed-off-by: Simon McVittie <smcv@collabora.com>
It's only used in test code. We have to put it in its own translation
unit with no non-libc dependencies so that we can compile a copy of it
without AddressSanitizer support, because in a subsequent commit we will
special-case test-segfault to be compiled without using AddressSanitizer,
which would make linking to an AddressSanitizer-instrumented libdbus fail.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Running tests under instrumentation (libasan) or emulation (qemu)
is not fast.
Inspired by the --timeout-factor option in
<https://salsa.debian.org/ci-team/autopkgtest>.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This results in (harmless) leak reports when running under the
AddressSanitizer, which could make real leaks harder to find.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Autotools creates executable applications in the respective
subdirectory of the build directory, while cmake creates
them in <build-root>/bin.
This leads to different paths in the file created
from org.freedesktop.DBus.TestSuite.PrivServer.service.in,
which are fixed by the new variable.
Bug: https://gitlab.freedesktop.org/dbus/dbus/issues/135
Signed-off-by: Ralf Habacker <ralf.habacker@freenet.de>
Reviewed-by: Simon McVittie <smcv@collabora.com>
After starting the test on Windows 10, whether the local user is an
administrator or not, a dialog box appears with a warning that some
features of the app have been blocked by the firewall and prompts for
credentials for an administrator account while the test continues to
run and pass.
If this request is aborted, the dialog disappears; no restrictions are
visible for the test case. When the test is restarted, the dialog is also
no longer displayed.
In the firewall configuration you can then see that test-server-oom.exe
has been added (but not enabled) for public networks, although no
confirmation has been received from an administrator account.
On Windows, the "out" parameter for the process handle isn't set
unless we specify G_SPAWN_FLAGS_DO_NOT_REAP_CHILD. That means we
can't terminate it, and the child process is leaked. When running the
test individually, the leaked process is harmless apart from its
resource cost, but when running under CTest, it holds a file descriptor
open (or something) which causes CTest to not exit.
If we *do* specify G_SPAWN_FLAGS_DO_NOT_REAP_CHILD, we become
responsible for "reaping" the child process by waiting for its exit
status, which is an OS-specific action.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Resolves: https://gitlab.freedesktop.org/dbus/dbus/issues/238
In at least some build configurations that target Windows, we see CRLF
newlines in the stderr of the subprocess. Leave the newlines unspecified
and let "*" match them.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Resolves: https://gitlab.freedesktop.org/dbus/dbus/issues/243
test-shutdown expects a GUID in the bus address by default,
which is not available under Windows, because on this platform
an autolaunch address is provided by dbus-run-session and is
not returned by dbus-daemon.
Bug: https://gitlab.freedesktop.org/dbus/dbus/merge_requests/59
Reviewed-by: Simon McVittie <smcv@collabora.com>
In an unprivileged container, uid 0 doesn't have CAP_SYS_RESOURCE, so
we can't expect the dbus-daemon to be able to escalate its fd limit.
This can be reproduced using bubblewrap:
sudo bwrap \
--cap-drop CAP_SYS_RESOURCE \
--ro-bind / / \
--dev /dev \
env \
DBUS_TEST_DAEMON=.../bus/dbus-daemon \
DBUS_TEST_DATA=.../test/data \
.../test/test-dbus-daemon \
-p /fd-limit \
--verbose
Bug-Debian: https://bugs.debian.org/908092
This simplifies bootstrapping: now you don't have to build dbus,
build dbus-python (with GLib), and use dbus-python to test dbus.
It also avoids test failures when using facilities like
AddressSanitizer. When libdbus is built with AddressSanitizer, but the
system copies of Python and dbus-python were not, dbus-python will exit
the Python interpreter on load, because libasan wasn't already
initialized. The simplest way to avoid this is to not use Python:
the scripts are not *that* hard to translate into C.
Both of these tests happen to be conditionally compiled for Unix only.
test_activation_forking() relies on code in TestSuiteForkingEchoService
that calls fork(), which can only work on Unix; meanwhile,
test_system_signals() tests the system bus configuration, which is
only relevant to Unix because we don't support using dbus-daemon as
a privilege boundary on Windows (and in any case D-Bus is not a Windows
OS feature, so the system bus cannot be used to communicate with OS
services like it can on most Linux systems).
This is also a partial solution to
<https://gitlab.freedesktop.org/dbus/dbus/issues/135>, by reducing the
size of name-test/.
For this to work, we need to build the test-service helper executable
even if embedded tests are disabled.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The implementation of the max-connections-per-user limit works in terms
of Unix uids, so it doesn't apply on Windows.
This is not a problem in practice, because it only makes sense to limit
connections per user if you have multiple users, and we don't support
the well-known system bus on Windows.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Previously, we were waiting a few seconds for the dbus-daemon to stop
listening, then trying to connect again and asserting that it failed,
then immediately asserting that the socket had actually been deleted.
However, there is a race here: the dbus-daemon stops listening on the
socket, and then deletes it. If the test client wins the race by
probing to see whether the socket is present after the dbus-daemon
has stopped listening but before the dbus-daemon has deleted it, then
the test will fail.
This intermittently happens on Gitlab-CI, most recently in
<https://gitlab.freedesktop.org/smcv/dbus/-/jobs/45694>.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is a wrapper for g_test_incomplete(), which works around bugs in
that function prior to GLib 2.57.3. I originally wrote it for librsvg.
Signed-off-by: Simon McVittie <smcv@collabora.com>
We might need these to run tests at build-time, so we should build them
whenever either modular or embedded tests are enabled, even if
installed-tests aren't.
We haven't noticed this bug until now because $(installable_helpers)
only contained test-apparmor-activation, which isn't normally needed at
build-time because the AppArmor test can only work when run as root.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The timeout we're using here is 0.5s (500ms), but the actual time taken
is unbounded, because the OS scheduler might not schedule our process
for an arbitrary length of time after we become runnable.
We previously allowed up to 1 second, but in the CI jobs for dbus!9
and dbus!18 we've seen this take up to 3.4 seconds (presumably
because other tests, or other jobs running on the same shared
infrastructure, starved this process). Allow up to 10 seconds to guard
against spurious failures.
The timeout used in the production system.conf is 150 seconds (2½
minutes), and we're only using the shorter 500ms timeout here to make
the test complete more quickly, so ±10 seconds is relatively
insignificant: the main thing is that it's finite.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The Desktop Entry Specification doesn't give any special meaning to
backslashes in section names: a line "[\n]" starts a section whose
name is the two characters (backslash, n), not a section whose name
is a newline. GKeyFile in GLib matches this interpretation.
In practice, the only section used by dbus-daemon is "D-BUS Service",
only way this could make a difference is if someone had written it
as "D-BUS\sService". According to
https://codesearch.debian.net/search?q=%5C%5BD-BUS%5C%5CsService%5C%5D
there is no instance of that pattern in Debian.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Instead of the previous adaptation of the existing template
for the session bus, a separate template is now used, which
can be more easily adapted to the requirements of the test
applications.
Bug: https://gitlab.freedesktop.org/dbus/dbus/issues/57
minimal.conf is a valid config file added to make it obvious why
the new invalid config files are invalid.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=107739
This is an easy bit of missing test coverage detected by running the
test suite with gcov.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=107739
These tests are very reliant on their custom LOG_COMPILER,
which AX_VALGRIND_CHECK replaces.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=107194
We don't need to do this for connections that were never set up
with the main loop.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=107194
Not all of these tests will be fully valgrind-clean yet (or perhaps
ever), but it's easier to add this to all of them than to think
about it.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=107194
AX_VALGRIND_CHECK overrides LOG_COMPILER, which means we can't rely
on running under glib-tap-test.sh. Default to TAP mode by modifying
our (effective) argv instead.
If you really want the default behaviour (unstructured output) this
can still be achieved by adding some arguments that are a no-op,
such as `-m quick`.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=107194
test_server_setup() takes a reference to the DBusServer, so we need
to release that ref by calling test_server_shutdown().
test_server_shutdown() also disconnects the server, so we don't need
to do that.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=107194
