Hopefully this has better uptime than snapshot.debian.org, which is
really an archival service rather than a production component.
This particular autoconf-archive version was in Ubuntu 16.10, so it
should stay around for a while.
Signed-off-by: Simon McVittie <smcv@debian.org>
This is a fairly pointless feature to add, since the current behaviour
was to abort due to a NULL pointer dereference shortly after the OOM
failure. At least now people will get a helpful error message when they
try to use dbus-send on a machine with incurable memory pressure.
Coverity ID: 54710
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99759
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Check that at most one argument which sets the payload is provided, so
the allocated payload is not overwritten and leaked.
Coverity ID: 54759
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99693
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Debian stable, Debian testing and Ubuntu LTS provide a reasonable
spectrum of old and new distributions. I'm only doing one build on
each to avoid a combinatorial explosion of options.
The Docker images don't have any deb-src apt sources set up, so don't
use `apt-get build-dep`; just include dependencies manually.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=98889
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
[smcv: move comment to install script as suggested]
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=98889
Taken from the version I added to OSTree.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=98889
set -u forces us to set all variables that we use (for example with the
${foo:=bar} syntax to take an existing value or set a default), or use the
${foo:-bar} syntax to make it explicit that the variable might be unset.
set -o pipefail (which is a bash feature) detects failure in non-last
elements of a pipeline.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=98889
This aligns it with the more generic script based on this one that
I sent to OSTree.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=98889
This realigns it with the script loosely based on this one that I
sent to OSTree.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=98889
This avoids confusion with the meaning of "release" used by
AX_IS_RELEASE. AX_IS_RELEASE is about facts about the source tree,
namely the distinction between releases (tags) and random snapshots.
The build variants in .travis.yml are about facts about the build
being done, namely the distinction between production and
debug/developer builds.
Production builds are sometimes referred to as "release builds",
for example in typical CMake and MSVC build environments, but a
different term seems better here.
Signed-off-by: Simon McVittie <smcv@debian.org>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=97357
[smcv: cherry-picked from master to dbus-1.10 to get the Travis-CI setup
consistent between the two branches]
Annoyingly, the POSIX way to declare environ (as
"extern char **environ") is a redundant declaration in glibc with
_GNU_SOURCE; work around that.
We also have a workaround for _NSGetEnviron() needing to be used
instead of direct access to environ in at least some circumstances on
Mac OS. Attempt to sync that up between all the files that use environ,
consistently sorting the most special special-cases first (Windows
for files that are compiled there, then Mac, then GNU, with
lowest-common-denominator POSIX last).
The affected files are already OS-specific, so I'm not bothering to
introduce a nicer or higher-level API for this.
Based on the best bits of an earlier patch from me, and an earlier
patch from Thomas Zimmermann.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Thomas Zimmermann <tdz@users.sourceforge.net>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=97357
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
This avoids confusion with the meaning of "release" used by
AX_IS_RELEASE. AX_IS_RELEASE is about facts about the source tree,
namely the distinction between releases (tags) and random snapshots.
The build variants in .travis.yml are about facts about the build
being done, namely the distinction between production and
debug/developer builds.
Production builds are sometimes referred to as "release builds",
for example in typical CMake and MSVC build environments, but a
different term seems better here.
Signed-off-by: Simon McVittie <smcv@debian.org>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=97357
This patch fixes warnings from '-Wsuggest-attribute=noreturn'. We cannot
enable it unconditionally as it would break libtool.
Signed-off-by: Thomas Zimmermann <tdz@users.sourceforge.net>
DBus uses custom rules in its Makefiles to implement test-coverage
statistics.
This patch implements test-coverage statistics with the autoconf macro
AX_CODE_COVERAGE. The script automatically tests for tools (e.g., gcov,
lcov), sets build variables and creates Makefile rules.
Run 'configure' with '--enable-code-coverage' to enable support for
test-coverage statistics. Run 'make check-code-coverage' to run the
tests and generate the statistics.
Signed-off-by: Thomas Zimmermann <tdz@users.sourceforge.net>
[smcv: do not alter compiler.m4; move AM_CXXFLAGS to the one place we
compile C++]
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=88922
In Debian bug <https://bugs.debian.org/829348>, lightdm appears to
have been starting dbus-launch with at least one of the three
standard fds 0, 1, 2 (stdin, stdout, stderr) closed. This resulted
in the dbus-daemon's epoll_create1() returning a fd less than 3.
Later, _dbus_become_daemon() replaces fds 0-2 with /dev/null. As a
result, a subsequent call to _dbus_loop_add_watch() for the reload
pipe resulted in calling epoll_ctl on the non-epoll fd pointing to
/dev/null, which fails with EINVAL, resulting in the dbus-daemon
exiting unsuccessfully.
Unix programs are not normally expected to behave correctly when
launched with the standard fds not already open; but at the same time,
X11 autolaunching means that dbus-launch (and hence the dbus-daemon)
can get started from an arbitrarily precarious situation.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=97008
Signed-off-by: Simon McVittie <smcv@debian.org>
Reviewed-by: Thiago Macieira <thiago@kde.org>
(cherry picked from commit c8f73a2a3a)
If dbus-daemon or systemd replied to our method call with an error,
we would report it as "invalid arguments" instead of the true error
name and message.
Same root cause as <https://bugs.freedesktop.org/show_bug.cgi?id=96653>.
Signed-off-by: Simon McVittie <smcv@debian.org>
In Debian bug <https://bugs.debian.org/829348>, lightdm appears to
have been starting dbus-launch with at least one of the three
standard fds 0, 1, 2 (stdin, stdout, stderr) closed. This resulted
in the dbus-daemon's epoll_create1() returning a fd less than 3.
Later, _dbus_become_daemon() replaces fds 0-2 with /dev/null. As a
result, a subsequent call to _dbus_loop_add_watch() for the reload
pipe resulted in calling epoll_ctl on the non-epoll fd pointing to
/dev/null, which fails with EINVAL, resulting in the dbus-daemon
exiting unsuccessfully.
Unix programs are not normally expected to behave correctly when
launched with the standard fds not already open; but at the same time,
X11 autolaunching means that dbus-launch (and hence the dbus-daemon)
can get started from an arbitrarily precarious situation.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=97008
Signed-off-by: Simon McVittie <smcv@debian.org>
Reviewed-by: Thiago Macieira <thiago@kde.org>
This is more suitable for distributions' Xsession scripts: it verifies
that X is already available, and so never results in an attempt to poll
stdin.
We read the machine UUID because it is needed to set the X atoms.
x11_init() assumes that the machine UUID (global variable) has been
set, either via read_machine_uuid_if_needed() or save_machine_uuid().
This is pretty tangled, but to make The Right Thing happen
automatically, we'd need to redo dbus-launch in terms of DBusError.
Reviewed-by: Will Thompson
Reviewed-by: Thiago Macieira
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=39197
Signed-off-by: Simon McVittie <smcv@debian.org>
Some D-Bus daemon versions set multiple addresses separated by semi-colon,
which breaks sourcing of the file.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=94746
Signed-off-by: Thiago Macieira <thiago@kde.org>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Some D-Bus daemon versions set multiple addresses separated by semi-colon,
which breaks sourcing of the file.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=94746
Signed-off-by: Thiago Macieira <thiago@kde.org>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
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>
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>
This fixes signedness mismatch warnings on platforms where socklen_t
is unsigned, notably Linux (where it's an unsigned int).
We still use int for the fallback case where the platform does not
define socklen_t, because that was the traditional (pre-POSIX) type:
for details see NOTES in Linux accept(2),
<http://manpages.debian.org/cgi-bin/man.cgi?query=accept&sektion=2>.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=93069
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
The idea is that .travis.yml is specific to Travis-CI, but most of the
actual work is done in tools/ci-build.sh, which should be reasonably
CI-platform-agnostic (it currently assumes that build-dependendencies are
preinstalled, that the "native" platform we're building on is GNU/Linux
or something very close, and that "mingw" means mingw-w64 as packaged
in Debian and Ubuntu).
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=93194
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
The idea is that .travis.yml is specific to Travis-CI, but most of the
actual work is done in tools/ci-build.sh, which should be reasonably
CI-platform-agnostic (it currently assumes that build-dependendencies are
preinstalled, that the "native" platform we're building on is GNU/Linux
or something very close, and that "mingw" means mingw-w64 as packaged
in Debian and Ubuntu).
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=93194
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
The warnings are fixed by adding functions to dbus string name
space returning unsigned char pointer, which avoids the need to
use casts.
Bug: https://bugs.freedesktop.org/attachment.cgi?id=93069
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Use the standard C99 PRI*64 macros instead of checking for specific GNU
libc version. We also specifically check for windows which does not have
proper C99 support.
This fixes printing of int64 on non-GNU 32 bit systems (like musl libc).
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92043
Reviewed-by: Thiago Macieira <thiago@kde.org>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
[smcv: fix extra % in the Windows fallbacks; include <inttypes.h> where needed]
A normal DBusConnection will automatically reply to o.fd.Peer
messages such as Ping. We don't want this: if we are using
traditional eavesdropping with an older dbus-daemon, we'll
confuse everyone else by replying to messages that weren't
intended for us. If we are using the new Monitoring
interface (since 1.9.12), the same still applies, but in
addition, the dbus-daemon will disconnect us for not being
a well-behaved monitor.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=90952
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
