Switch the order of the argument checks to avoid the
-Wduplicated-branches warning.
Signed-off-by: David King <dking@redhat.com>
Reviewed-by: Simon McVittie <smcv@collabora.com>
EAGAIN and EWOULDBLOCK are documented to possibly be numerically equal,
for instance in errno(3), and a simple logical OR check will trigger the
-Wlogical-op warning of GCC. The GCC developers consider the warning to
work as-designed in this case:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69602
Avoid such a warning by explicitly checking if the values are identical.
Fixes: https://gitlab.freedesktop.org/dbus/dbus/issues/225
Signed-off-by: David King <dking@redhat.com>
Reviewed-by: Simon McVittie <smcv@collabora.com>
dbus-run-session is the preferred way to run a temporary D-Bus
session scoped to the lifetime of a process, for example
dbus-run-session -- make check.
Bug: https://gitlab.freedesktop.org/dbus/dbus/issues/193
Otherwise test-segfault will not be able to disable core dumps, making
it extremely slow and noisy to run the tests under cmake.
I added the missing checks in commit be55374f, but didn't add the
corresponding symbols to config.h.cmake.
Fixes: be55374f "cmake: check for the necessary symbols for test-segfault.c"
Closes: https://gitlab.freedesktop.org/dbus/dbus/issues/227
Signed-off-by: Simon McVittie <smcv@collabora.com>
freedesktop.org Gitlab doesn't currently have enough test runners
available to run all of this every time. For higher-risk changes
(for example those that change the build system) we can run the
complete set through the web UI.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Travis-CI workers have cmake preinstalled, but Gitlab-CI Docker images
typically don't.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=108177
Acked-by: Philip Withnall <withnall@endlessm.com>
This uses the same shell scripts as Travis-CI, with slightly different
settings. We use Docker containers for all our Gitlab-CI runs, so take
the opportunity to use Debian 9 'stretch' as our baseline, and
relegate Ubuntu 14.04 'trusty' to to a secondary build.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=108177
Acked-by: Philip Withnall <withnall@endlessm.com>
Open Build Service RPMs for mingw32-dbus-1 hard-code all the
directories to make everything explicit, notably:
--prefix=/usr/i686-w64-mingw32/sys-root/mingw
--exec-prefix=/usr/i686-w64-mingw32/sys-root/mingw
...
--libdir=/usr/i686-w64-mingw32/sys-root/mingw/lib
Previously we didn't accept this as relocatable, but actually it's
fine: ${prefix} is still equivalent to ${libdir}/pkgconfig/../..,
so our relocation setup can work. Accept the result of expanding
"${prefix}" as an acceptable value for --exec-prefix, and accept the
results of expanding "${exec_prefix}/lib" etc. as acceptable values
for --libdir.
Note the use of single vs. double quotes here. A case statement that
matches '${prefix}' tests for the literal string «${prefix}»,
whereas a case that matches "${prefix}" tests for the string that is
the value of the variable named «prefix» that is set by the
--prefix command-line argument.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=107662
There are two reasons why we might reject relocation: the exec_prefix
differing from the prefix, or the libdir not being a first-level
subdirectory named "lib" or "lib64" of the prefix. Make it clearer
which one failed and why.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=107662
This improves test coverage, because
bus_container_instance_lost_connection() was previously only called
when we failed to set up a connection with a server due to OOM, but
it is now also called (instead of being duplicated) when we are told
to clean up a connection because it has disconnected.
To make sure that connections from containers can never cheat their
way into being treated as uncontained, do not set their
contained_data_slot to NULL.
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
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
We have never checked the <!DOCTYPE> of busconfig XML since the libxml
parser was removed in 2013, and the libxml parser was broken before
that anyway. The recommended Expat parser (our only parser since 2013)
does not appear to have ever validated this, so now does not seem like
the time to start. Just ignore the <!DOCTYPE> if there is one.
(We never validated this particularly strictly anyway;
<!DOCTYPE busconfig SYSTEM "http://example.com/bees"> would have been
treated as perfectly valid.)
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 do not appear in code coverage statistics, and `git grep`
reveals that they are unused.
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
As noted in GLib commit c879f50f, gcc's interpretation of the malloc
attribute has become more strict over time, which could result in
miscompilation. The new definition is that in addition to assuming
that the returned memory block is newly-allocated, gcc now assumes
that it does not contain any valid pointers. This is OK for
uninitialized or zero-initialized memory returned by dbus_malloc()
or dbus_malloc0(), but not valid for dbus_realloc(), which might be
used for a dynamically-sized array of (structures containing)
valid pointers.
See https://gitlab.gnome.org/GNOME/glib/issues/1465
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=107741
This saves around 32% of the size of the archive.
[smcv: Rebased onto current master]
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=107630
The changelogs (and the commits themselves, converted to git format)
are still in the git history if anyone needs them.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
https://bugs.freedesktop.org/show_bug.cgi?id=107630
Running the "embedded tests" through valgrind revealed that before this
commit, we would have been willing to read up to 3 bytes off the end of
a message if the message is truncated part way through a boolean. Any
practical allocator will round up allocations to the next 32-bit (or
larger) boundary, so in practice this will not leave the memory buffer
(and in particular did not crash during unit testing), but it could read
uninitialized contents.
On little-endian CPUs, an attacker might be able to use this to learn
whether up to 3 bytes of uninitialized memory in the dbus-daemon
were all-zero (their crafted message would be relayed) or not (their
connection would be disconnected for sending an invalid message). On
big-endian CPUs, an attacker might be able to use this to learn whether
up to 3 bytes were all-zeroes (relayed to a cooperating peer), 0-2
bytes of all-zeroes followed by 0x01 (relayed to a cooperating peer),
or something else (disconnected). This is not believed to be exploitable
to leak interesting information.
Fixes: 62e46533 "hardcode dbus_bool_t to 32 bits"
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=107332
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Thiago Macieira <thiago@kde.org>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
It's just painfully slow, particularly when we fork (as we do in
test-bus to test service activation).
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
Instead of having separate test wrappers for the cases that do and
don't take a DBusConnection, we can just pass a NULL DBusConnection
to the one that doesn't.
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
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
If re-initializing the string fails, it will be left in a state
where it has a length of 0 and a NULL buffer. That's valid to
"free", but not valid to pass to rmdir().
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
