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>
Using PRId64, etc. to print dbus_int64_t or dbus_uint64_t is not 100%
portable. On platforms where both long and long long are 64-bit (such as
Linux and macOS), we will prefer to define dbus_int64_t as long.
If the operating system has chosen to define int64_t as long long,
which is apparently the case on macOS, then the compiler can warn that
we are passing a long argument to PRId64, which is "lld" and therefore
expects a long long argument (even though that ends up with the same
bit-pattern being used).
We can't necessarily just use int64_t and uint64_t directly, even if all
our supported platforms have them available now, because swapping
dbus_int64_t between long and long long might change C++ name mangling,
causing ABI breaks in third-party libraries if they define C++ functions
that take a dbus_int64_t argument.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Otherwise, Coverity will diagnose this as a resource leak,
because it doesn't understand that our assertions end up guaranteeing
that the result is freed if and only if it's non-`NULL`.
Coverity CID: 354884
Assertions can be disabled, but in test code the assertions are the
whole point, so use checks that can't be disabled instead.
Because there's a lot of test code, I haven't done this globally, only
in the tests that I recently converted from "embedded" to "modular".
Signed-off-by: Simon McVittie <smcv@collabora.com>
Assertions can be disabled; but in test code the assertions are the
entire point, so we don't want to disable them. Use _dbus_test_fatal()
instead.
test-service is actually a test helper rather than a test, so use its
pre-existing die() function instead.
Signed-off-by: Simon McVittie <smcv@collabora.com>
These previously relied on embedding test-specific code in libdbus,
but they actually only need public APIs, private interfaces that get
exported anyway for the benefit of dbus-daemon, and the TAP helpers;
so we can run them even in production builds.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This doesn't verify that they're atomic, but does verify that they
return the right things.
This commit adds a new test function _dbus_test_check (a) to make
writing tests easier. It checks the given boolean expression and
generates a "not ok" test result if the expression is false.
Due to the current design of the test api, the test is only compiled
if embedded tests were enabled at the time of configuration.
It was also necessary to move the test_atomic target definitions in
test/Makefile.am to the --enable-embedded-tests section to avoid a
make distcheck build error.
The test case itself has been authored by smcv.
Co-authored-by: Simon McVittie <smcv@collabora.com>
Instead of exposing _dbus_sha_test() as a private exported symbol,
we can expose _dbus_sha_compute(), which is the only thing called by
the test that isn't already exported.
Signed-off-by: Simon McVittie <smcv@collabora.com>
We don't actually complete successful authentication, because that
would require us to generate a cookie and compute the correct SHA1,
which is difficult to do in a deterministic authentication script.
However, we do assert that dbus#269 (CVE-2019-12749) has been fixed.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This requires exposing _dbus_connection_get_address() as an internal
symbol, but that seems worth it.
Signed-off-by: Simon McVittie <smcv@collabora.com>
dbus-marshal-recursive-util.c contains utility functions used by the
other two, as well as tests. The others are purely test code.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This required exposing one additional internal symbol:
_dbus_hash_table_ref(). I think that's a reasonable trade-off for not
compiling this test into the library.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This makes it easier for a developer to run just the fast parts while
debugging some issue reproduced by the faster tests.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Now that there is no code outside test/ that calls into this, we can
move it into test/, reducing the size of libdbus.
dbus-test-tap.[ch] still need to stay in dbus/ as long as there is
code in dbus/ or bus/ relying on them, and also need to be linked into
libdbus as long as there is other code in libdbus relying on them,
so they stay where they are for now. Similarly, dbus-tests.h lists
the tests that are still embedded in libdbus, and must stay where
it is for the moment.
With this move, various tests now need to be linked to the dbus-testutils
convenience library.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This groups them with the rest of the tests, and enables parts of
the test code to be unembedded from libdbus and moved to test/ too.
Rename the executable to test-misc-internals, not test-dbus. The name
test-dbus made some sense as "the executable that contains the code in
dbus/", but makes a lot less sense in test/: dbus is the name of the
entire project, so this test has no particular special claim to that
name. test-libdbus doesn't seem right either, because all the tests
exercise libdbus one way or another.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This test is sufficiently well-separated that there's no real need
to embed it in libdbus. Move it into the test directory instead.
Signed-off-by: Simon McVittie <smcv@collabora.com>
If the environment variable DBUS_TEST_SLOW is not set or is 0
fewer iterations are performed in test-refs enough to demonstrate
that it works, rather than seriously trying to reproduce race
conditions.
This solves the long runtime that Wine 3.x (4 times longer than
native Windows 7) or Windows 7 as a VirtualBox 5.22 guest (10
times longer) is to be seen.
Fixes#244
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>
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
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>
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
