Simon McVittie [Fri, 15 Jul 2022 14:41:14 +0000 (15:41 +0100)]
test/bus: Break up dispatch test into three separate tests
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>
Simon McVittie [Mon, 18 Jul 2022 10:14:08 +0000 (11:14 +0100)]
test: Skip tests that involve switching uid if unable to do so
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>
Simon McVittie [Fri, 1 Apr 2022 17:56:26 +0000 (18:56 +0100)]
sysdeps: Only open oom_score_adj read/write if we need to write it
If we're running in a sandbox, we might not have write access to
oom_score_adj. In the common case where we don't have any special
protection from the OOM-killer, we can detect that with only read
access, and skip the part where we open it for writing.
(We would also not have write access to oom_score_adj if we're running
with elevated Linux capabilities while not root, but that should never
actually happen for dbus-daemon-launch-helper, which is setuid root
for production use or has no capabilities during unit-testing.)
Signed-off-by: Simon McVittie <smcv@collabora.com>
Simon McVittie [Fri, 1 Apr 2022 17:58:34 +0000 (18:58 +0100)]
activation-helper: Never crash if unable to write oom_score_adj
_dbus_warn() normally only logs a warning, but can be made fatal by
environment variables. In particular, we do that during unit testing,
which can result in a build-time test failure if dbus is built in a
sandbox environment that prevents write access.
_dbus_log() does only the logging part of _dbus_warn(), which seems
more appropriate here.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The comment refers to the nul-padding of sockaddr_un member sun_path and
using an addrlen of sizeof(sockaddr_un). There is not much need to
document an old now "broken" behaviour.
Simon McVittie [Fri, 15 Jul 2022 14:08:02 +0000 (15:08 +0100)]
dbus-launch-x11: Ignore X11 connection when checking for memory leaks
The X11 connection is opened and never closed. Because dbus-launch
forks and continues to run non-trivial code in a forked child, it is
not clear whether (or where) it would be safe to close it; instead, we
leave it open until process exit, at which point the socket is cleaned
up by the kernel.
Any memory allocated for the X11 connection is only allocated once per
run of dbus-launch, so there's no need to keep track of it, and we can
silence these memory leak warnings as uninteresting.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Simon McVittie [Fri, 15 Jul 2022 11:13:43 +0000 (12:13 +0100)]
meson: Set up functionally necessary compiler arguments separately
We have to set up feature-flag options like _GNU_SOURCE before we
do compiler checks like cc.has_header_symbol, otherwise we'll miss
symbols that are guarded by a feature-flag test, like environ in Linux
unistd.h.
However, we don't want to pass flags for extra compiler warnings
when doing these checks, because that can cause false negatives:
in particular, Meson's check programs nearly always trigger -Wunused.
So the warnings need to be in a separate list.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Simon McVittie [Fri, 15 Jul 2022 00:37:47 +0000 (01:37 +0100)]
test: Work around TAP test regression in Meson 0.63.0
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>
Simon McVittie [Mon, 27 Jun 2022 16:13:52 +0000 (17:13 +0100)]
CI: Explicitly build before running tests
If we don't do this, Meson will build everything that is a direct
dependency of the test executables, but it won't build indirect
dependencies like GLib's gspawn-win32-helper.exe.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Simon McVittie [Mon, 27 Jun 2022 10:14:06 +0000 (11:14 +0100)]
CI: Enable Ducktype-based documentation on Debian/Ubuntu
We don't currently know the equivalent of python3-mallard-ducktype on
other OSs like openSUSE, but we know this should work on Debian (it does
when we do Autotools builds).
Signed-off-by: Simon McVittie <smcv@collabora.com>
Simon McVittie [Mon, 27 Jun 2022 11:41:41 +0000 (12:41 +0100)]
CI: Verify that Autotools `make dist` includes everything needed for Meson
This is similar to what we have done for CMake since dbus/dbus!87
(commit 1063bba "CI: Do the CMake native debug build from an Autotools
`make dist`"). Our official source releases are Autotools `make dist`
tarballs, so our CI should assert that such tarballs contain everything
necessary to do a CMake or Meson build, so that downstream distributions
using our tarballs as source can choose their preferred build system.
When the Meson build system is ready to be recommended as more preferred
than Autotools, we can do as GLib did: stop releasing `make dist`
tarballs, and start releasing `meson dist` tarballs instead (which will
change nothing for Meson or CMake users, but Autotools users will have
to run autoreconf or autogen.sh before building).
Signed-off-by: Simon McVittie <smcv@collabora.com>
Simon McVittie [Wed, 13 Jul 2022 16:55:27 +0000 (17:55 +0100)]
meson: Don't use cc.has_function to check for va_copy
va_copy is not an ordinary function (an extern symbol), so we can't
treat it as one. Instead, use the same compilation/linking check as
in the Autotools build system.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
[smcv: Rename to avoid using "Win32" to refer to both 32- and 64-bit] Signed-off-by: Simon McVittie <smcv@collabora.com>
projects / thirdparty / dbus.git / log
