This means we can finally use patterns like this:
DBusString buffer = _DBUS_STRING_INIT_INVALID;
dbus_bool_t ret = FALSE;
... some long setup ...
if (!_dbus_string_init (&buffer))
goto out;
... some long operation ...
ret = TRUE;
out:
... free things ...
_dbus_string_free (&buffer);
... free more things ...
return ret;
without having to have a separate boolean to track whether buffer has
been initialized.
One observable difference is that if s is a "const" (borrowed pointer)
string, _dbus_string_free (&s) now sets it to be invalid. Previously,
it would have kept its (borrowed pointer) contents, which seems like
a violation of least-astonishment.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=89104
It's easier to implement a stack-allocated string that is valid to
free (but for no other purpose) if we consider all-bits-zero to be
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=89104
These tests were disabled by commit 9c3d566, which rewrote the D-Bus
type system to be fully recursive, back in 2005. The message builder
was subsequently removed by commit 9d21554, also in early 2005.
It will probably take significant work to turn these files into
test-cases that use the current D-Bus type system and so can be run
this decade. Until that work is done, let's not ship them: we can
always fetch them from git history if we want them.
The single .message-raw file can still be read and has been retained,
although it hasn't actually tested the intended failure mode since
2005 due to changes to the D-Bus specification (it is a wire-protocol
version 0 message, and the recursive type system introduced in commit
9c3d566 changed the wire-protocol version to 1).
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103758
If we crash, we'll want to know what the most recent diagnostic was.
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103601
This lets us see which bits are painfully slow. (Spoilers:
check_existent_service_no_auto_start.)
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103601
The echo service frequently fails to connect to the bus when we are
testing OOM code paths, again causing a lot of noise in the log.
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103601
In parts of the OOM testing, our logging produces multiple megabytes
of output. Let's not do that.
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103601
stdout and stderr are close-on-exec and buffered, so we can't rely on
their buffers being empty. If we continue to execute application code
after forking (as opposed to immediately exec()ing), then the child
process might later flush the libc stdio buffers, resulting in
output that is printed by the parent also being printed by the child.
In particular, test-bus.log sometimes grows extremely large for
this reason, because this test repeatedly attempts to carry out
legacy activation.
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103601
This is a little more self-documenting - it justifies why it's
acceptable to fail hard on out-of-memory conditions. _dbus_test_fatal()
isn't compiled unless we are compiling embedded tests, so compiling
with embedded tests disabled provides reasonable confidence that we
aren't using _dbus_test_fatal() inappropriately.
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103601
Unlike _dbus_assert_not_reached(), this new function takes a printf-style
format string, so we don't need to use a _dbus_warn() to explain why
the failure occurred (unless the failure message is multi-line).
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103601
Reviewed-by: Philip Withnall <withnall@endlessm.com>
[smcv: Add an explanatory comment as suggested]
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103601
This is still not how warnings and diagnostics should be done
(the advice should probably be included in the DBusError) but at least
this way it won't interfere with machine-readable output on stdout.
See also https://bugs.freedesktop.org/show_bug.cgi?id=103756
Reviewed-by: Philip Withnall <withnall@endlessm.com>
[smcv: Added a reference to #103756]
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103601
Printing to stdout would interfere with generating TAP syntax.
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103601
While reviewing fd.o#101354, Philip Withnall pointed out that if we
rejected a connection in the new code there, we didn't log why. It
turns out we didn't log that in the more normal code path either.
Redo the error handling so that failure to set up a connection
is logged.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103592
(cherry picked from commit 56847ae818)
While reviewing fd.o#101354, Philip Withnall pointed out that if we
rejected a connection in the new code there, we didn't log why. It
turns out we didn't log that in the more normal code path either.
Redo the error handling so that failure to set up a connection
is logged.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103592
In the debug build, enable features that are off by default. In the
reduced build, explicitly disable features, some of which are
on by default. In the legacy build, check that we can compile the
default feature-set without inotify, dnotify, systemd, etc.
Reviewed-by: Philip Withnall <withnall@endlessm.com>
[smcv: Rebase onto 1.13.x branch, fix minor conflicts]
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101354
(cherry picked from commit 3c031ef5aa)
If we combine the dbus_new0, populating the DBusString members and the
actual creation of the file, RAII-style, then we never need to worry
about a partially-initialized or uninitialized DBusNonceFile becoming
visible to a caller.
Similarly, if we combine deletion of the file, freeing of the
DBusString members, freeing the structure and clearing the pointer to
the structure, then we can never be in an inconsistent situation,
except during the actual implementation of _dbus_noncefile_delete().
Note that there are two implementations each of
_dbus_noncefile_create() and _dbus_noncefile_delete(). This is because
on Unix we must use a subdirectory of _dbus_get_tmpdir() (the nonce
filename is not created atomically, so that would not be safe), while
on Windows we use the directory directly (the Windows temp directory
is private to a user, so this is OK).
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103597
This was always leaked, both on success and on error.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103597
(cherry picked from commit 37d5af203c)
We could free all of these without having ever successfully
initialized them.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103597
(cherry picked from commit 6d08f5c04e)
If _dbus_string_init() fails, it doesn't guarantee that the string
is initialized to anything in particular. Worse, if
_dbus_string_init (&buffer) fails, p would never have been initialized
at all, due to the use of the short-circuiting || operator.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103597
(cherry picked from commit 0ea0e4b0fd)
This was always leaked, both on success and on error.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103597
We could free all of these without having ever successfully
initialized them.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103597
If _dbus_string_init() fails, it doesn't guarantee that the string
is initialized to anything in particular. Worse, if
_dbus_string_init (&buffer) fails, p would never have been initialized
at all, due to the use of the short-circuiting || operator.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103597
_dbus_string_init_const() doesn't include the trailing '\0' in
the DBusRealString->len, so this surely shouldn't either.
In practice none of the users of _DBUS_STRING_DEFINE_STATIC care one
way or the other, but it seems better to be consistent.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=89104
This will be used in a test for connecting to container servers
as the wrong uid.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101354
Instead of calling g_test_skip() internally, raise a distinctive error
and let the caller handle 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=101354
This will be used in tests later in the branch.
Sadly we can't use GLIB_VERSION_2_44 unless we are willing to have a
hard dependency on GLib 2.44, which would force us to do all our
Travis-CI builds in Docker containers rather than in ye olde base
system, and that adds 50% to the time taken to do builds.
Reviewed-by: Philip Withnall <withnall@endlessm.com>
[smcv: Rebase onto 1.13.x branch, fix minor conflicts]
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101354
The regular expression previously used here to select the second
comma-delimited argument won't work when we introduce an argument
containing a comma, which I need to do now. We can address this by
recognising Autoconf's quoting mechanism (which uses square
brackets).
This is not 100% right (it doesn't understand nested square brackets),
but it's good enough in practice.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Acked-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101354
In the debug build, enable features that are off by default. In the
reduced build, explicitly disable features, some of which are
on by default. In the legacy build, check that we can compile the
default feature-set without inotify, dnotify, systemd, etc.
Reviewed-by: Philip Withnall <withnall@endlessm.com>
[smcv: Rebase onto 1.13.x branch, fix minor conflicts]
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101354
