configure.ac will detect PYTHON=python3 if there is no python
executable in the PATH.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101716
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>
It is too easy for a developer working in an environment that has a
session bus to write tests that pass locally, but fail in minimal
environments. This is also risky because the tests might do
destructive things on the developer's real session bus. We can avoid
connecting to the session bus by consistently removing its address
from the environment, and replacing it with something that will
always fail.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101698
test-pending-call-disconnected relies on being run under a session bus.
On master, the TESTS in this directory all get that treatment, but
in dbus-1.10 they do not. This caused test-pending-call-disconnected
to fail in minimal environments like travis-ci where there is no
developer-initiated session bus.
Backport part of commit ec6b220 "name-test: run most C tests directly,
not via run-test.sh" to wrap it in dbus-run-session. This is better
than putting it in run-test.sh because this way, its TAP output is
parsed directly by Automake.
It also has the side benefit of exercising dbus-run-session in the
automated tests.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101698
The error message was leaked when blocking on a pending call after
the connection was disconnected.
Reviewed-by: Philip Withnall <withnall@endlessm.com>
[smcv: re-word commit message]
Reviewed-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101481
The error message was leaked when blocking on a pending call after
the connection was disconnected.
Reviewed-by: Philip Withnall <withnall@endlessm.com>
[smcv: re-word commit message]
Reviewed-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101481
According to git history, this test was written in 2006 by Red Hat
employee John Palmieri and has received only trivial changes since
then. Red Hat gave permission in 2007 for their contributions to
be relicensed under the MIT/X11 license. We cannot take advantage
of that permission to relicense the core library or the dbus-daemon
from GPL-2+|AFL-2.0 to MIT/X11, because one early copyright holder
(CodeFactory AB) could not be traced, but we might as well use a
permissive license for simple test code that has not had
CodeFactory AB contributions.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101481
At the moment there is a hack in the implementation of GetMachineId()
to stop tests from failing during "make check" on a system where
dbus has never been installed, by silently generating a new unique
fake "machine ID" for each process. I'm about to change that
behaviour to report errors properly; skip affected test-cases if we
can't read the real machine ID.
The shell scripts to test dbus-launch are run both as "make check"
tests (for which it is valid for dbus to be not correctly installed)
and as installed-tests (for which that is not valid), so make them
pass during "make check" but fail during installed testing.
The tests in bus/ and test/name-test/ are only run during "make check"
so they only have the code path where they are skipped.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=13194
This is mostly pointless, but will shut Coverity up.
Coverity ID: 54718
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99724
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
This is mostly pointless, but should shut Coverity up.
Coverity ID: 54693
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99722
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Also take the opportunity to tweak the test-threads-init messages
slightly to make it more TAP-compliant. It is not entirely TAP compliant
because it doesn’t print a test plan before starting its tests.
Coverity IDs: 54701, 54714, 54726
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99694
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
This is not a security vulnerability because it's test code that
should never be compiled in production.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
As a general design principle, strings that we aren't going to modify
should usually be const. When compiling with -Wwrite-strings, quoted
string constants are of type "const char *", causing compiler warnings
when they are assigned to char * variables.
Unfortunately, we need to add casts in a few places:
* _dbus_list_append(), _dbus_test_oom_handling() and similar generic
"user-data" APIs take a void *, not a const void *, so we have
to cast
* For historical reasons the execve() family of functions take a
(char * const *), i.e. a constant pointer to an array of mutable
strings, so again we have to cast
* _dbus_spawn_async_with_babysitter similarly takes a char **,
although we can make it a little more const-correct by making it
take (char * const *) like execve() does
This also incorporates a subsequent patch by Thomas Zimmermann to
put various string constants in static storage, which is a little
more efficient.
Signed-off-by: Simon McVittie <smcv@debian.org>
Reviewed-by: Thomas Zimmermann <tdz@users.sourceforge.net>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=97357
We want to emulate the behaviour of the system bus, but we don't
really want to spam the system log with lots of test messages.
Signed-off-by: Simon McVittie <smcv@debian.org>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=97009
The exception is test-autolaunch, which is really not particularly
useful as a build-time test. The only way we can really test
autolaunch is as a whole-system integration test, and "make check"
is not that.
The two tests written in Python and one test based on dbus-send
are also not run directly yet; in particular, that includes both
the tests in run-test-systemserver.sh.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92899
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Similar to commit 58eefa1031.
test-privserver is a helper executable, not a test. I moved its output
from stdout to stderr so it can't be misinterpreted as the test's
stdout.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92899
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Instead of using $DBUS_USE_TEST_BINARY to control whether to use the
hard-coded test binary TEST_BUS_LAUNCH_BINARY, we can just use
$DBUS_TEST_DBUS_LAUNCH to control what we launch directly, as we
were already doing for $DBUS_TEST_DAEMON.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92899
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
The exception is test-autolaunch, which is really not particularly
useful as a build-time test. The only way we can really test
autolaunch is as a whole-system integration test, and "make check"
is not that.
The two tests written in Python and one test based on dbus-send
are also not run directly yet; in particular, that includes both
the tests in run-test-systemserver.sh.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92899
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Similar to commit 58eefa1031.
test-privserver is a helper executable, not a test. I moved its output
from stdout to stderr so it can't be misinterpreted as the test's
stdout.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92899
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Instead of using $DBUS_USE_TEST_BINARY to control whether to use the
hard-coded test binary TEST_BUS_LAUNCH_BINARY, we can just use
$DBUS_TEST_DBUS_LAUNCH to control what we launch directly, as we
were already doing for $DBUS_TEST_DAEMON.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92899
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
The wrapper shell script that sets up their environment is nowhere
near being portable. In particular, it uses dbus-run-session,
which is Unix-specific.
[rh: Add autotools scope in commit title]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92899
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Rewieved-by: Ralf Habacker <ralf.habacker@freenet.de>
Now that we're normally linking libdbus-1 dynamically, we need to
use DBUS_STATIC_BUILD_CPPFLAGS in every Makefile that would normally
link it dynamically, but might link it statically if we are only
building static libraries.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=83115
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
The shared can be used by dbus-daemon and dbus-daemon-launch-helper by exporting
the private symbols needed, reducing the size of dbus by about 500k.
The private symbols are exposed under the version
LIBDBUS_PRIVATE_@VERSION_NUMBER@.
[Altered by Simon McVittie and Ralf Habacker to clear up some
problematic linking.]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=83115
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
This gets rid of a potential circular dependency, which is annoying
when bootstrapping. It is nice to have the regression tests use
the shared libdbus, but we're about to make it possible to
do that anyway, even though some of them use internal symbols.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=83115
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
pygobject 2 is obsolete and unmaintained, and anyway this is for
optional functionality (full regression test coverage) rather than
anything that will be needed in production builds.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=85969
That implementation no longer exists, so neither 0xABCDEF nor 0xABCDEF2
has any special meaning any more.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=54972
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Alban Crequy <alban.crequy@collabora.co.uk>
We don't want the regression tests' "session" getting mixed up in
system-wide "sessions". This doesn't actually matter yet, but it is
likely to matter in future.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=61301
Reviewed-by: Chengwei Yang <chengwei.yang@intel.com>
[merged with earlier line-wrapping of TESTS_ENVIRONMENT -smcv]
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
There are two ways to find the dbus-daemon for testing. The first one is
defined as string at compile stage and the second one is export it from
test environment.
The first way has limitation that after defined, it's static string, so
it's impossible to run installable check. So let's unify to the second
way.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=37849
[added missing "}" -smcv]
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
In practice, it won't; other forms of autolaunch (like Mac OS launchd)
might, but we can't really assert either way.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=40352
Reviewed-by: Chengwei Yang <chengwei.yang@intel.com>
[amended to reinstate use of dbus/dbus-sysdeps.h which was removed
by 412538b3b9 -smcv]
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
When do autolaunch testing, libdbus will try to start dbus-launch in
installed direcotry, if fail then fall back to dbus-launch in $PATH.
dbus-launch does a relative better thing to start dbus-daemon in build
directory, however, in most of case, the build $prefix is different from
the real prefix where dbus-daemon installed. So dbus-daemon will fail to
start due to can't find its config file. And then dbus-launch will fall
back to finally the installed dbus-daemon.
This patch fix this behavior and will start dbus-launch and dbus-daemon
in build directory in test environment.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=37849
We only use dbus-glib for its main loop; within dbus, DBusLoop is
available as an alternative, although it isn't thread-safe and
isn't public API.
For tests that otherwise only use libdbus public API, it's desirable to
be able to avoid DBusLoop, so we can run them against an installed
libdbus as an integration test. However, if we don't have dbus-glib,
we're going to have to use an in-tree main loop, which might as well
be DBusLoop.
The major disadvantage of using dbus-glib is that it isn't safe to
link both dbus-1 and dbus-internal at the same time. This is awkward
for a future test case that wants to use _dbus_getsid() in dbus-daemon.c,
but only on Windows (fd.o #54445). If we use the same API wrapper around
both dbus-glib and DBusLoop, we can compile that test against dbus-glib
or against DBusLoop, depending on the platform.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=68852
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
It's sufficiently portable that GLib has an equivalent, and I really
don't want to have to either open-code it in dbus-run-session or
link dbus-run-session statically. We have enough statically-linked
rubbish already.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=39196
Reviewed-by: Colin Walters <walters@verbum.org>
This lets them be thread-safe by default, at the cost that they can
now fail.
init_uninitialized_locks() and init_global_locks() must now both
reimplement the equivalent of _dbus_register_shutdown_func(), by using
_dbus_platform_rmutex_lock() on the same underlying mutex around a call
to _dbus_register_shutdown_func_unlocked().
This is because if they used the usual _DBUS_LOCK() API (as
_dbus_register_shutdown_func() does), it would automatically try to
initialize global locking, leading to infinite recursion.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=54972
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Alban Crequy <alban.crequy@collabora.co.uk>
Reviewed-by: Anas Nashif <anas.nashif@intel.com>
...except for CheckForAbstractSockets.c, which runs before config.h is
generated, and sd-daemon.c, which is externally-maintained.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=59971
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Colin Walters <walters@verbum.org>
When libdbus-1 moved to using monotonic time support for the
DBUS_COOKIE_SHA1 authentication was broken, in particular
interoperability with non-libdbus-1 implementations such as GDBus.
The problem is that if monotonic clocks are available in the OS,
_dbus_get_current_time() will not return the number of seconds since
the Epoch so using it for DBUS_COOKIE_SHA1 will violate the D-Bus
specification. If both peers are using libdbus-1 it's not a problem
since both ends will use the wrong time and thus agree. However, if
the other end is another implementation and following the spec it will
not work.
First, we change _dbus_get_current_time() back so it always returns
time since the Epoch and we then rename it _dbus_get_real_time() to
make this clear. We then introduce _dbus_get_monotonic_time() and
carefully make all current users of _dbus_get_current_time() use it,
if applicable. During this audit, one of the callers,
_dbus_generate_uuid(), was currently using monotonic time but it was
decided to make it use real time instead.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=48580
