This makes it possible for projects to incorporate D-Bus as a CMake sub-project in a larger CMake project.
Before this PR, doing so would result in many errors.
This is because CMAKE_SOURCE_DIR and CMAKE_BINARY_DIR would point to directories above the D-Bus project.
Using paths relative to the project directory, PROJECT_SOURCE_DIR and PROJECT_BINARY_DIR, corrects for this.
This is really three separate test-cases: one for traditional
activation as a direct child process of the dbus-daemon, and two for
traditional activation (successful and failing) via the setuid
dbus-daemon-launch-helper on Unix.
The ones where activation succeeds extremely slow, as a result of the
instrumentation for simulating malloc() failures combined with a large
number of memory operations, particularly when using AddressSanitizer.
Splitting up "OOM" tests like these has a disproportionately good impact
on the time they take, because the simulated malloc() failure
instrumentation repeats the entire test making the first malloc() fail,
then making the second malloc() fail, and so on. For allocation failures
in the second half of the test, this means we repeat the first half of
the test with no malloc() failures a very large number of times, which
is not a good use of time, because we already tested it successfully.
Even when not using the "OOM" instrumentation, splitting up these tests
lets them run in parallel, which is also a major time saving.
Needless to say, this speeds up testing considerably. On my modern but
unexceptional x86 laptop, in a typical debug build with Meson, the old
dispatch test took just over 21 minutes, which drops to about 40 seconds
each for the new normal-activation and helper-activation tests (and for
most of that time, they're running in parallel, so the wall-clock time
taken for the whole test suite is somewhere around a minute).
In a debug build with Meson, gcc and AddressSanitizer, the old dispatch
test takes longer than my patience will allow, and the new separate
tests take about 5-6 minutes each. Reduce their timeout accordingly, but
not as far as the default for slow tests (5 minutes) to allow some
headroom for AddressSanitizer or slower systems.
The failed-helper-activation test is almost instantaneous, and no longer
needs to be marked as slow.
Signed-off-by: Simon McVittie <smcv@collabora.com>
In a Linux user namespace, it is possible that we are uid 0 but are
unable to switch to some other uid like DBUS_USER or DBUS_TEST_USER,
because the other uid is not "mapped" in the user namespace, resulting
in setuid() or setresuid() failing with EINVAL "Invalid argument".
For example, it's easy for this to happen when running under the
bubblewrap tool.
Try to drop privileges in a child process, and skip the test if we
are unable to do so.
Resolves: dbus#407
Signed-off-by: Simon McVittie <smcv@collabora.com>
With Meson 0.63.0, detailed output of TAP tests is not logged, and the
test deadlocks if the stderr pipe fills up. I'm hoping this will be fixed
before 0.63.1, but in the meantime we can work around it by falling back
to the 'exitcode' protocol: this means we lose machine-readable detailed
test results, but at least our tests pass.
See https://github.com/mesonbuild/meson/issues/10577 and
https://github.com/mesonbuild/meson/issues/10563 for details of the
Meson regression.
Signed-off-by: Simon McVittie <smcv@collabora.com>
When building for Windows, either natively or cross-compiling and
running tests with Wine, test-autolaunch-win expects to be able to
find the just-built dbus-daemon.exe in the PATH.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Group slow tests (those taking about a minute or more in one of the
configurations built on Gitlab-CI) into a new 'slow' suite, which can
be used with `meson test --no-suite=slow` to run just the faster tests.
They default to a 5 minute timeout (usually enough) unless overridden
(bus/dispatch.c can be *very* slow when OOM testing is enabled, and
gets a 30 minute timeout).
For the remaining tests, default to Meson's usual 30 second timeout,
but bump up the timeout a bit in some cases to have a safety margin
(my method was to take the slowest run on our Gitlab-CI, and make sure
we're allowing about 3 times that long).
Signed-off-by: Simon McVittie <smcv@collabora.com>
For as-installed testing on Unix, we want these to be symlinks to the
production versions of the same file.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is what we do with Autotools, and keeping Meson the same means we
can diff the installed trees more easily.
Signed-off-by: Simon McVittie <smcv@collabora.com>
DBUS_SESSION_BUS_LISTEN_ADDRESS is the same as in non-test files:
the test data distinguishes between DBUS_SESSION_BUS_LISTEN_ADDRESS,
the real session bus configuration, and TEST_LISTEN, the test-only
configuration.
DBUS_TEST_HOMEDIR and HOME should be in the build directory, not
the source directory.
Signed-off-by: Simon McVittie <smcv@collabora.com>
If a helper executable is not, in itself, a test-case, then we should
not generate metadata that tells ginsttest-runner to run it as a
test-case.
Meanwhile, we were previously generating foo_with_config.test metadata
for tests that don't get installed; stop doing that.
We also need to distinguish between the abstract name of the test
(which usually does not start with test-), the name of the .test file
(which does start with test- for compiled executables), and the name
of the executable (which may include .exe as well). To make validation
against the Autotools build system as straightforward as possible,
generate exactly the same names as in Autotools. We can consider removing
the test- prefix later, if we remove the Autotools build system.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Some items listed in the tests array are helper executables rather
than actually being tests, and should not be run as a test at any time.
Those have {"test": false}. Expand this special case to the scripts
array for completeness (although currently, no scripts need this).
Meanwhile, some items listed in the scripts array are "as-installed"
integration tests which cannot safely be run at build-time, because
they make assertions about the state of the installed system.
Introduce {"build_time_test": false} for these, and expand this special
case to the tests array for completeness (although currently, no
compiled executables need this).
Signed-off-by: Simon McVittie <smcv@collabora.com>
As long as we are treating Autotools as a first-class citizen, what we
release will be `make distcheck` output.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Some of the strings we need to substitute into these files are not
the same for as-installed testing as for build-time testing.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The test application performs several individual tests to detect possible
problems with the autostart support under Windows. Connections are tested
with the standard scope, a 'custom' scope, the 'install path' scope and
the 'user' scope.
Signed-off-by: Ralf Habacker <ralf.habacker@freenet.de>
The tests are enabled with the embedded tests; the required
low-level functions from the dbus library are decorated with
DBUS_EMBEDDED_TESTS_EXPORT to indicate the appropriate usage.
On Windows, all tests are run; on unix-like operating systems,
individual tests are disabled:
- the tests on #NULL pointers of type DBus[C|R]Mutex, since they
point to a data structure and would cause a segment violation
when accessed.
- the multiple lock test for type DBusCMutex, since it would block
the current thread.
Since the whole point of "rmutex" is to be able to lock multiple
times, the "rmutex double lock" test is enabled on unix-like
operating systems too.
Signed-off-by: Ralf Habacker <ralf.habacker@freenet.de>
To avoid that build break in test-marshall-recursive-util.c the newly
added function _dbus_string_append_buffer_as_hex() is used to print
the hex bytes.
Signed-off-by: Ralf Habacker <ralf.habacker@freenet.de>
To fix this problem, the problematic code was replaced by a new function
_dbus_string_get_allocated_size(), which uses the existing macro
DBUS_CONST_STRING_PREAMBLE for these purposes.
Signed-off-by: Ralf Habacker <ralf.habacker@freenet.de>
Part-of: https://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/275
Reviewed-by: Simon McVittie <smcv@collabora.com>
Only do the deliberate crash via undefined behaviour (which the compiler
is quite right to warn us about!) if raise() isn't available.
The pointer needs to be volatile otherwise the compiler is free to remove
the store.
Part-of: https://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/275
Reviewed-by: Simon McVittie <smcv@collabora.com>
