This function worked with a (string,position,length) triple, but it
turns out to only have one caller, which tells it to look at the
entire string anyway. It'll be easier to document if all the offsets
start from 0.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=100317
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>
Commit 0c03b505 was meant to clear all the fds indexed by j in
[0, n_fds), which socket_disconnect() can't be allowed to close
(because on failure the caller remains responsible for closing them);
but instead it closed the one we failed to add to the main loop
(fd i), repeatedly.
Similarly, it was meant to invalidate all the watches indexed by j
in [i, n_fds) (the one we failed to add to the main loop and the ones
we didn't try to add to the main loop yet), which socket_disconnect()
can't be allowed to see (because it would fail to remove them from
the main loop and hit an assertion failure); but instead it invalidated
fd i, repeatedly.
These happen to be the same thing if you only have one fd, resulting
in the test-case passing on an IPv4-only system, but failing on a
system with both IPv4 and IPv6.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=89104
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Also use test_oom() where the relevant lines are changing anyway.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103600
It seemed like a nice idea at the time, but I now think it's more
confusing than it's worth.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103600
Previously, we allocated m both during initialization, and after
deciding not to skip this test.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103600
This also covers _dbus_server_new_for_socket(), which is one of the
worse places in terms of complexity of the error-unwinding path
(3 labels).
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
dbus_realloc() doesn't guarantee to set errno (if it did, the
only reasonable thing it could set it to would be ENOMEM). In
particular, faking OOM conditions doesn't set it. This can cause an
assertion failure when OOM tests assert that the only error that can
validly occur is DBUS_ERROR_NO_MEMORY.
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
If _dbus_noncefile_create() has failed and set error, it is incorrect
for us to set it again.
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
If _dbus_server_new_for_socket() fails, it is the caller's
responsibility to close the fds. All other callers did this.
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
_dbus_server_finalize_base() asserts that the socket has been
disconnected, but in some OOM code paths we would call it without
officially disconnecting. Do so.
This means we need to be a bit more careful about what is
socket_disconnect()'s responsibility to clean up, what is
_dbus_server_new_for_socket()'s responsibility, and what is the caller's
responsibility.
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
We assert that every watch is invalidated before it is freed, but
in some OOM code paths this didn't happen.
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 is one of the few places that has test coverage for all the OOM
code paths. It was also one of the worst (most complicated)
error-unwinding locations, with labels failed_0 up to failed_4.
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 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
