This is more graceful than failing entirely (our previous behaviour),
but more visible than ignoring it completely (the previous behaviour
patched in by Debian and derivatives).
Based on a patch from Daniel Silverstone back in 2004, which was meant
to be temporary; I think it makes sense to change this permanently,
since files in *.d are typically supplied by other packages, whose bugs
shouldn't be able to bring down dbus-daemon.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=19186
Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=230231
Reviewed-by: Colin Walters <walters@verbum.org>
This is one of the patches from Maemo's dbus package. It seems to do all
of:
* fix some documentation
* remove unreached code to delete/free the nonce file from
_dbus_server_new_for_socket - doing that on failure violates
least-astonishment anyway
* in _dbus_server_new_for_tcp_socket, never fail without setting @error
* if we fail after creating the nonce file, delete it
* if we fail after allocating the nonce file struct, free it
Origin: vendor, Maemo
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=33128
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
This isn't thread-safe or reentrant, but it turns out we don't need
either of those properties, and readdir_r is a real pain to use correctly,
particularly in the presence of FUSE filesystems that might implement
statfs() wrong.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=8284
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=15922
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
Again, this shouldn't happen - modules are responsible for cleaning up
their watches - but the failure mode here is really bad: if we leave an
invalid fd in the set, every poll() call will instantly return, marking
it as POLLNVAL. The result is that dbus-daemon busy-loops on poll()
without responding to I/O, so the bad watch will probably never be
cleared up.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=32992
Bug-NB: NB#200248
Reviewed-by: Colin Walters <walters@verbum.org>
This shouldn't happen - other modules are responsible for cleaning up
their watches - but the bug fixed in my last commit has been present for
several years and I'm sure it's not the only one, so for robustness,
let's refuse to watch obviously-wrong file descriptors.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=32992
Bug-NB: NB#200248
Reviewed-by: Colin Walters <walters@verbum.org>
The code called from handle_watch() might close either or both of the
sockets we're watching, without cleaning up the DBusWatch. This results
in invalid file descriptors being passed to _dbus_poll(), which could
end up busy-looping on a POLLNVAL condition until the babysitter loses
its last ref (which automatically clears up both watches).
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=32992
Bug-NB: NB#200248
Reviewed-by: Colin Walters <walters@verbum.org>
This fixes a race condition: the server exits while the client continues
to the next iteration. If the server wins, the test passes. If the client
wins, it sends a message to the dying service, never gets a reply, and the
test fails.
My branch to refactor the main loop for fd.o #23194 seems to make the
client more likely to win this race, resulting in intermittent test
failures.
This is an instance of the general problem described by fd.o #11454.
This is similar to how ConnectionData works. Without this change, we
deserve to segfault: when the first set of callbacks (either watches or
timeouts) is cleaned up, we unref the server and loop, and free sd;
when the second set of callbacks is cleaned up, we use-after-free sd,
the server and the loop, then double-free sd.
However, due to fd.o #33277 we don't even get that far, because we've
already died with an assertion failure.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=33277
Use ./configure --docdir=/foo (or --htmldir=/foo) to control where it
ends up. For instance, Debian could use:
--docdir=/usr/share/doc/dbus-1-doc --htmldir='${docdir}/html'
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=13495
Helpfully, AC_CHECK_DECLS (which configure.in uses to define
HAVE_DECL_MSG_NOSIGNAL) behaves differently to every similar AC_CHECK_*
macro and, rather than producing #undef HAVE_DECL_MSG_NOSIGNAL if the
given symbol is not found, instead produces #define
HAVE_DECL_MSG_NOSIGNAL 0.
Mike McQuaid's patch fixes the uses of this constant in sysdeps-unix;
with this patch, all code is guarded consistently and correctly.
